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Call for Papers: Summer 1991 USENIX Conference 

Opryland Hotel, Nashville, TN, June 10-14, 1991 


Multimedia—Interfaces for Now 
and the Future 

Systems designers and multimedia develop¬ 
ers must face the challenge of how to support and 
deliver the new types of interfaces—voice, video, 
animated graphics, touch and music—that users 
are demanding now. While adding immeasurably 
to the power of the computer for communication 
and expression of ideas, the new media multiply 
system complexity and magnify the challenge of 
providing easy access to computer resources. 

What are the technical engineering require¬ 
ments to enable your operating systems to effec¬ 
tively process the new types of data? What must 
you, and your organization, do to prepare? 

How can we design new multimedia inter¬ 
faces to improve information handling? What 
projects are underway now that offer insight into 
the directions to be taken in developing fully in¬ 
tegrated multimedia systems with a coherent and 
meaningful framework? These are some of the 
questions tackled by presenters and attendees at 
the USENIX Summer 1991 Conference. 

Formats for Presentations 

The USENIX Summer 1991 Conference will 
provide a variety of forums in which attendees can 
explore multimedia issues, as well as more general 
operating system and environment questions. 

We invite submissions of your papers and 
multimedia presentations, describing new and ex¬ 
citing work, multimedia-related or not, for the 
technical track. Please target a sophisticated tech¬ 
nical audience, particularly knowlegeable about 
operating systems issues but also keenly inter¬ 
ested in new and exciting projects in many areas. 
Suggested topics include, but are not limited to: 

Multimedia, applications and research 

systems integrating voice, video, audio, touch, 
or music 

data compression technology 
user interface/human factors 
Hypermedia 

authoring systems 
hypermedia/multimedia documents 


Operating systems issues 
multiprocessor systems 
distributed systems 
secure systems 
fault tolerant systems 
systems for novel architectures 
distributed file systems 
Communications and networking 
protocols 
performance 

administration and security 
Programming environments 
user interfaces, windowing, graphics 
compilers and language technology 
software development and other support tools 
testing and debugging 
Sophisticated applications 
databases 

transaction processing 
instructional 

scientific, biological, medical, etc. 

Form of Submissions 

Submissions to the technical track should 
represent new work and be in the form of an 
abstract and outline. Be complete enough to pro¬ 
vide details of the approach and give the com¬ 
mittee confidence in the final paper. Full papers 
are accepted as well. A submission should be from 
3-5 pages and include: 

1. Author name(s), postal addresses, telephone 
numbers, and e-mail addresses. 

2. Abstract: 100-300 words. 

3. Outline: 2-5 pages giving enough details of the 
approach or algorithms to allow the committee to 
understand and judge the submission. 

4. References and citations to relevant literature. 
Show you are aware of previous work (and not 
reinventing the wheel). 

5. Time needed for presentation. Slots are usually 
30 minutes but adjustment can be made when 
in-depth background or audio-visual support is 
desirable. 

6. Audio-visual presentation description and re¬ 
quirements. We are happy to provide assistance 
and equipment to make your presentation as au¬ 
rally and visually appealing as possible. 


January/February 1991 
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Authors whose submissions are accepted will 
receive instructions for the preparation of final 
papers to be published in the conference pro¬ 
ceedings. Once your paper is accepted you will 
need to provide an electronic (source) copy. We 
are looking into possibilities for making audio and 
video materials as well. 

Relevant Dates 

Abstracts and outlines due: February 6, 1991 
Notifications to authors: March 4, 1991 
Final papers due: April 19, 1991 

Please submit one hard copy and one elec¬ 
tronic copy to the address below: 

Deborah K. Scherrer 

Nashville USENIX Technical Program 

mt Xinu 

2560 Ninth Street 
Berkeley, CA 94710 

Internet: nashville@usenix.org 
UUCP: uunet!usenix.org!nashville 

Telephone (415) 644-0146 
FAX (415) 644-2680 

Be sure to include your postal and electronic 
mail addresses in all correspondence. 


Program Committee: 

Deborah K. Scherrer (Chair) 

mt Xinu 

Eric P. Allman 

University of California , Berkeley 
Frances Brazier 
Vrije Universiteit 
Tom Duff 

AT&T Bell Laboratories 
Daniel E. Geer 
Digital Equipment Corp. 

Stanley P. Hanks 
Baylor College of Medicine 
Michael Hawley 
MIT Media Lab 
Jun Murai 
Keio University 
Alan G. Nemeth 
Digital Equipment Corp. 

Jeff Peck 

Sun Microsystems 

Charles E. Perkins 

IBM T. J. Watson Research Center 

Gretchen Phillips 

State University of New York at Buffalo 

Charles S. Roberts 

Hewlett-Packard 

Larry Stead 

Bellcore 

Avadis Tevanian 
NeXT, Inc. 


Special Exhibition Opportunity: 

Emerging Technology Companies 

The USENIX Association is hosting a special exhibits forum for young high technology companies at 
its Summer 1991 Conference and Exhibition. This program for the 1991 Conference and Exhibition 
will bring young companies with innovative products in touch with an advanced computing community 
looking for new solutions. 

To help introduce new UNIX-related advanced computing products or products in development to the 
technical community, USENIX provides young companies with: 

• special exhibitor savings package 

• promotional assistance 

• publicity support 

The usenix Association Summer 1991 Conference and Exhibition will be held June 10-14 at the 
Opryland Hotel in Nashville, Tennessee. The Association encourages young high technology com¬ 
panies to contact: 

Cynthia Deno, Exhibits Manager 
usenix Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
408/335-5646 

email: cynthia@usenix.org, uunet!usenix!cynthia 
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SERC 


acm 


IEEE COMPUTER SOCIETY 


Symposium on Experiences with Distributed 
and Multiprocessor Systems (SEDMS) II 
Preliminary Program March 21-22, 1991, Atlanta, GA 


Goal 



This Symposium will bring together individ¬ 
uals who have built, are building, or will soon 
build distributed and multiprocessor systems, es¬ 
pecially operating systems. The symposium will 
feature refereed presentations on aspects of build¬ 
ing, testing, debugging, and using these systems. 
The Symposium will provide a forum for individ¬ 


uals to exchange information on their experi¬ 
ences, both good and bad, including those with 
coding aids, languages, distributed debugging 
tools, prototyping, reuse of existing software, per¬ 
formance analysis, and lessons learned from use 
of such systems. 


Thursday, March 21 

8:30 am Opening remarks 

George Leach , General Chair 
Gene Spafford , Program Chair 

8:45 am Keynote presentation: How to Move Parallel Processing into the Mainstream? 

Professor H. T. Kung , School of Computer Science, Carnegie-Mellon University 

9:45 am Break 

10:15 am Session I — System-Building Experience 

Experience Developing the RP3 Operating System 
Ray Bryant, Hung-Yang Chang and Bryan Rosenburg , 

IBM Research Division, Thomas J. Watson Rsearch Center 

Experiences with Distributed Data Management in Real-time C3 Systems 
Paul J. Fortier , Naval Underwater Systems Center, 

David V. Pitts, John C. Sieg, Jr, and C. Thomas Wilkes , 

Department of Computer Science, University of Lowell 
The ION Data Engine 
Marc F, Pucci , Bellcore 

Building a Semi-Loosely Coupled Multiprocessor System Based on Network Process 
Extension 

Helen S. Raizen and Stephen C. Schwarm , Prime Computer Inc. 

12:15 pm Lunch (on your own) 

1:30 pm Session II — RPC and Communications 

Implementation and Performance of a Communication Facility for Distributed Transaction 
Processing 

Bharat Bhargava and Enrique Mafia , Department of Computer Sciences, 

Purdue University 

Experience with Threads and RPC in Mach 
Dan Duchamp, Computer Science Department, Columbia University 
Kernel-Kernel Communication in a Shared-Memory Multiprocessor 
Eliseu M . Chaves , Jr., Thomas J . LeBlanc, Brian D. Marsh and Michael L. Scott , 
Computer Science Department, University of Rochester 


January/February 1991 
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3:45 pm Session III — Scheduling Synchronization 

Process Scheduling and Synchronization in the Renaissance Object-Oriented 
Multiprocessor Operating System 

Vincent F . Russo , Department of Computer Sciences, Purdue University 

A Hybrid Approach to Load Balancing in Distributed Systems 
Prabha Gopinath , Philips Laboratories, and 

Rajiv Gupta , Department of Computer Science, University of Pittsburgh 

FALCON: A Distributed Scheduler for MIMD Architectures 
Andrew S. Grimshaw and Virgilio E . Vivas 
Department of Computer Science, University of Virginia 

5:30 pm Work-in-Progress Session 

Moderator: Mike O'Dell , Bellcore 

8:30 pm Optional discussion/panel session: Orthogonal Optimization Languages in Distributed 

Systems 

(plus other discussion, debates, etc.) 

Friday, March 22 

8:30 am Planning for SEDMS III 

Leach! Spaffor d 

8:45 am Session IV — Debugging and Analysis 

Performance Evaluation of the Sylvan Multiprocessor Architecture 
Forbes J. Burkowski , C. L. A. Clarke , S. C. Cowan and G. J. Vreugdenhil , 
Department of Computer Science, University of Waterloo 

Debugging Multiprocessor Operating System Kernels 
Noemi Paciorek, Susan LoVerso and Alan Langerman 
Encore Computer Corporation 

Debugging the Time Warp Operating System and Its Application Programs 
Peter L . Reiher , Jet Propulsion Laboratory, Steven Bellenot , 

Florida State University, and David Jefferson , UCLA 

11:00 am Session V — Performance Tuning 

Lock Granularity Tuning Mechanisms in SVR4/MP 
Mark D. Campbell , Russ Holt and John Slice 
NCR Corporation, EM Columbia 

Measured Performance of Caching in the Sprite Network File System 
Brent Welch , Xerox-PARC CSL 

1:30 pm Session VI — Distributing Memory and Data 

Using Kernel-Level Support for Distributed Shared Data 

David L . Cohn , Paul M. Greenawalt , Micheal R . Casey and Matthew P. Stevenson® 
Department of Computer Science and Engineering, University of Notre Dame 

Virtual Memory Xinu 

Douglas Comer and James Grifftoen , 

Department of Computer Sciences, Purdue University 

Early Experience with Building and Using the Gothic Distributed Operating System 
Isabelle Puaut, Michel Banatre and Jean-Paul Routeau 
IRISA-INRIA 
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3:30 pm Session VII — Distributed Systems 

Supporting an Object-Oriented Distributed System: Experience with UNIX, 

Mach and Chorus 

F. Boyer , J. Cayuela , P. Y. Chevalier , A. Freyssinet, and Daniel Hagimont , 
Bull-IMAG/Systemes 

Can We Study Design Issues of Distributed Operating Systems in a Generalized Way? 

G. W. Gerrity, Andrzej Goscinski , J. Indulska, W. Toomey and W. Zhu , 

Department of Computer Science, University College, University of New South Wales 

Distributed Programming Environments in the Clouds Operating System 
Partha Dasgupta, R. Ananthanarayanan } Sathis Menon , Ajay Mohindra, 

Mark P. Pearson, Ray Chen and Chris Wilkenloh , Distributed Systems Laboratory, 
College of Computing, Georgia Institute of Technology 


Alternate Paper 

Alternate paper (to appear in proceedings, but not presented at the Symposium): 


Experiences with the Liason Network Multimedia Workstation 
Howard P. Katseff Robert D. Gaglianello , Thomas B. London , Bethany S. Robinson and 
Donald B. Swicker, ATT Bell Laboratories 


Program Committee 

John Barr 
Motorola , Inc. 

Bharat Bhargava 

Department of Computer Sciences, 
Purdue University 


Michael Scott 

Computer Science Department , 
University of Rochester 

Roger Shultz 
Rockwell International 


David L. Cohn 

Department of Computer Science and Engineering , 
Univ. of Notre Dame 

George Leach 
Paradyne Corp. 

Mike O'Dell 
Bellcore 


Gene Spafford 

Software Engineering Research Center! 
Department of Computer Sciences, 
Purdue University 

Satish Tripathi 

Department of Computer Science , 
University of Maryland 


Karsten Schwan 
College of Computing, 

Georgia Institute of Technology 
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The First Conference On Computers, Freedom & Privacy 
Tutorials & Invitational Conference, March 25-28, 1991 
Airport SFO Marriott Hotel, Burlingame, California 

Sponsored by the Computer Professionals for Social Responsibility 


About Computers, Freedom & Privacy 

We are at a crossroads as individuals, orga¬ 
nizations and governments depend more and 
more on computers and computer networks. 
Within ten years, most global information will be 
collected and utilized electronically. 

The 1990’s are the pivotal decade in which 
statutes, policies and judicial precedents will 
be developed for controlling access, use — and 
abuse — of computerized information and elec¬ 
tronic mail. Current government and private- 
sector policies are an uncoordinated jumble, cre¬ 
ated as each group evolves ways to collect, 
manipulate, extract, share and protect comput¬ 
erized and networked information and services. 

Data on individuals and groups is being com¬ 
puterized by numerous agencies, organizations 
and special interests, often without the knowledge 
or approval of those it concerns, and with varying 
degrees of accuracy. Computers can greatly assist 
individuals, organizations and government in 
making sound decisions based on efficient access 
to adequate information — for personal benefit, 
business improvement and national well-being. 
Or, inappropriate use and regulation can seriously 
threaten fundamental freedoms, personal pri¬ 
vacy, and the democratic processes that are at the 
very foundation of this nation and of any free 
society. 

Conference Sessions: March 26-28 
Plenary Speakers: 

• Laurence H. Tribe, Professor of Constitu¬ 
tional Law, Harvard Law School, offering 
major policy proposals in the opening Con¬ 
ference session, “The Constitution in Cy¬ 
berspace: Law & Liberty Beyond the Elec¬ 
tronic Frontier.” 

• Eli M. Noam, Director of the Center for 
Telecommunications and Information 
Studies, Columbia University, and a rec¬ 
ognized leader in telecommunications reg¬ 


ulation, international communications pol¬ 
icies and economics, will discuss, “Network 
Environments of the Future: Reconciling 
Free Speech and Freedom of Association.” 

• William A. Bayse, Assistant Director, FBI 
Technical Services Division, Washington 
DC, providing perspectives on “Balancing 
Computer Security Capabilities with Pri¬ 
vacy and Integrity” at the Wednesday 
evening banquet. 

The Conference sessions offer diverse speak¬ 
ers and panel discussions: 

Trends in Computers & Networks. Overview 
and prognosis of computing capabilities and net¬ 
working as they impact personal privacy, confi¬ 
dentiality, security, one-to-one & many-to-one 
communications, and access to information about 
government, business and society. 

International Perspectives & Impacts. Other 
nations models for protecting personal informa¬ 
tion and communications, and granting access to 
government information; existing and developing 
laws; requirements for trans-national dataflow 
and their implications; impacts on personal ex¬ 
pression; accountability. 

Personal Information & Privacy. Govern¬ 
ment and private collection, sharing, marketing, 
verification, use, protection of, access to and re¬ 
sponsibility for personal data, including buying 
patterns, viewing habits, lifestyle, work, health, 
school, census, voter, tax, financial and consumer 
information. 

Law Enforcement Practices & Problems. Is¬ 
sues relating to investigation, prosecution, due 
process and deterring computer crimes, now and 
in the future; use of computers to aid law en¬ 
forcement. 

Law Enforcement & Civil Liberties. Interac¬ 
tion of computer crime, law enforcement and civil 
liberties; issues of search, seizure and sanctions, 
especially as applied to shared or networked in¬ 
formation, software and equipment. 
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Legislation & Regulation. Legislative and 
regulatory roles in protecting privacy and insuring 
access; legal problems posed by computing and 
computer networks; approaches to improving re¬ 
lated government processes. 

Computer-based Surveillance of Individuals. 

Monitoring electronic-mail, public & private tele¬ 
conferences, electronic bulletin boards, publica¬ 
tions and subscribers; monitoring individuals, 
work performance, buying habits and lifestyles. 

Electronic Speech, Press & Assembly. Free¬ 
doms and responsibilities regarding electronic 
speech, public and private electronic assembly, 
electronic publishing, prior restraint and chilling 
effects of monitoring. 

Access to Government Information. Imple¬ 
menting individual and corporate access to fed¬ 
eral, state & local information about communi¬ 
ties, corporations, legislation, administration, the 
courts and public figures; allowing access while 
protecting confidentiality. 

Ethics & Education. Ethical principles for 
individuals, system administrators, organizations, 
corporations and government; copying of data, 
copying of software, distributing confidential in¬ 
formation; relations to computer education and 
computer law. 

Where Do We Go From Here? Perspectives, 
recommendations and commitments of partici¬ 
pants from the major interest groups, proposed 
next steps to protect personal privacy, protect 
fundamental freedoms and encourage responsible 
policies and action. 

Tuesday and Wednesday will include struc¬ 
tured opportunities for attendees to identify 
groups with whom they want to establish contact 
and, if they wish, announce topics they would like 
to discuss, one on one. 

This is an intensive, multi-disciplinary survey 
conference for those concerned with computing, 
teleconferencing, electronic mail, computerized 
personal information, direct marketing informa¬ 
tion, government data, etc. — and those con¬ 
cerned with computer-related legislation, regula¬ 
tion, computer security, law enforcement and 
national and international policies that impact 
civil liberties, responsible exercise of freedom and 
equitable protection of privacy in this global In¬ 
formation Age. 


Tutorials: Monday, March 25 

Seminars on the first day offer introductions 
to the different disciplines that intersect in this 
conference. These are surveys for individuals not 
already expert in the topics presented. These half¬ 
day tutorials are scheduled in four parallel tracks: 

Global Communications & the Worldwide Com¬ 
puter Matrix. 

Low-Cost Computer Networking & Computer 
Bulletin Board Systems. 

Current & Proposed International Policies. 
Federal Legislation Impacting Computer Use. 
How Computer Crackers Crack! 

How Computer Crime is Investigated. 
Information Security. 

Conference Chair 

Jim Warren, Autodesk, Inc. and MicroTimes 

Program Committee 

Dorothy Denning, Digital Equipment Corpora¬ 
tion 

Peter Denning, Research Institute for Advanced 
Computer Science 

Les Earnest, SF Peninsula ACLU & Stanford 
University, ret. 

Elliot Fabric, Attorney at Law 
Mark Graham, Pandora Systems 
Don Ingraham, Alameda County District Attor¬ 
ney Us Office 

Bruce Koball, Motion West 
Marc Rotenberg, Computer Professionals for 
Social Responsibility 

Glenn Tenney, Fantasia Systems & Hacker's 
Conference 

This invitational conference is limited to 600 
participants. To facilitate useful dialogue and bal¬ 
anced participation by representatives from all of 
the diverse groups interested in these issues, at¬ 
tendance is limited. All interested individuals are 
encouraged to request an invitation. Invitations 
will be primarily issued on a first-come, first- 
served basis within each major interest group. For 
a complete brochure and invitation contact: 

CFP Conference, 

345 Swett Road, 

Woodside CA 94062 

Sponsor: Computer Professionals for Social 
Responsibility, (415)322-3778 
E-mail: cfp@well.sf.ca.us Fax: (415)851-2814 
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Call For Papers: Second UNIX Security Workshop 

May 1991, Milan, Italy 


Organized by MI.NE.R.S. for University 
Students 

Chairman: Prof. Giancarlo Martella 
Sponsored by the Italian Computer and Auto¬ 
matic Calculus Association, Commodore Italy, 
Computer Science Dept., IBM Italy, and the 
usenix Association. 

This UNIX Security workshop will be held at the 
Computer Science Department of Milan Univer¬ 
sity during the last week of May 1991. The work¬ 
shop will be open to students, researchers, and 
professors. Everyone who intends to present a 
paper must send the organizing secretary an ab¬ 
stract, consisting of no more than 4000 words, 
before March 15, 1991. The topics of interest are 
UNIX security, privacy and the affordability of 
UNIX systems. 


Suggested specific topics: 

Hackers, crackers, method of intrusions, and 
how to defend systems. 

Bugs description and suggested patches. 
Viruses, Trojan horses, logic bombs. 
Automatic methods for protection. 
Password security. 

Authors will be notified of their acceptance before 
March 31, 1991. The definitive paper should be 
sent to the organizing secretary before April 30, 
1991. 

Organizing Secretary: 

MI.NE.R.S. 

MIN4SEC c/o D.S.I. 

Via Moretto da Brescia, 9 - 20133 Milano 
Tel. 039-2-7575238 Fax: 039-2-76110556 
E-mail: min4sec@dsinextl.unimi.it 


UniForum Research Award Program 


In an effort to advance the state of the art in 
UNIX and open systems in the areas of computer 
science and management science, UniForum, the 
International Association of UNIX Systems Users, 
is offering its second annual UniForum Research 
Award Program. Awards, up to two years in du¬ 
ration, will include a stipend of up to $10,000 per 
year. Two awards will be given each year, one to 
a candidate seeking an advanced degree in the 
technical study of computer sciences and the other 
to a candidate seeking an advanced degree in 
management sciences as they apply to information 
management. The award is designed to help stu¬ 
dents research solutions to problems in the UNIX/ 
Open Systems community. Preference will be 
given to research which concludes with demon¬ 
strable results that can be shown at the UniForum 
show and is of value to UniForum Association 
sponsors. 

Candidacy is open to individuals pursuing a 
graduate-level, qualifying degree from an accred¬ 
ited university. Candidates will be chosen based 
upon their specific research proposal along with a 
demonstrated history of academic excellence. All 
work performed as a result of the UniForum Re¬ 
search Award shall be in the public domain 


though, of course, UniForum will be free to pub¬ 
lish the work and research results. 

Each recipient of the UniForum Research 
Award will be required to submit a one-page 
status report to the Executive Director of Uni¬ 
Forum each quarter and a four-to-five page 
progress report at the end of the first year of the 
award period (in the case of two-year awards), for 
review and approval to continue. At the conclu¬ 
sion of the award period, a formal paper will be 
required. Formal presentation of the work at the 
UniForum conference is expected. Student ap¬ 
plications and proposals should be submitted to 
their Department Chairman for his or her review. 
Each university can then nominate up to two 
candidates for the award. Application deadline is 
May 1,1991. Winners will be notified July 1,1991. 

To obtain an application, contact: 

UniForum Research Award Committee 
Attn: Ed Palmer 
2901 Tasman Dr., #201 
Santa Clara, CA 95054 

Phone: (408) 986-8840 or (800) 255-5620 
FAX (408) 986-1645 
Email: uunet!usrgrp!ed 
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Call for Tutorial Proposals 

In an effort to continue to provide the best 
possible tutorials to its membership, the Associ¬ 
ation would like to solicit proposals for future new 
tutorials. The proposals can cover any subject, 
ranging from introductory to advanced materials, 
although one should avoid overly introductory 
materials (i.e., a one day tutorial on “Introduc¬ 
tion to C Programming” is not what we are look¬ 
ing for). Previous conferences have included tu¬ 
torials on such diverse topics as UNIX Network 
Programming, X Toolkit Intrinsics, Topics in Sys¬ 
tem Administration, Mach Virtual Memory In¬ 
ternals, System V and Berkeley Kernel Internals, 
and Software Contracts and Intellectual Property, 
among many others. 

Tutorials usually run for a full day (6 hours 
of class time plus morning, lunch, and afternoon 
breaks), although we are currently experimenting 
with halfday (3 hour) tutorials. A proposal should 
include a statement of what you want to teach, 
and a coherent outline of your tutorial (not simply 
a list of what you want to cover, but the order in 
which you want to cover it, with an estimate on 
the amount of time for each subject). We need to 
know that you can comfortably fill a 6 hour class, 
but not overfill it (i.e., that you won’t suddenly 
discover at 4:30 that you have another 3 hours of 
slides left to present). 

If you have any supplementary materials to 
distribute (e.g., copies of papers, shell scripts, 
source code, illustrations, etc.), give an indication 
of the volume of supplementary material, and a 
rough count of the number of slides you will be 
presenting during class. (Historically, a typical 
tutorial has between 75-200 slides, along with up 
to 200 pages of supplementary material). If pos¬ 
sible, include a couple of sample slides (one with 
text, one with graphics) with your proposal. If 
you have a complete or draft course already done, 
a copy of the current materials would be most 
useful. 


We also need to know if you will be pre¬ 
senting or distributing any source code. If so and 
you do not hold the copyright, you must be able 
to demonstrate that you have permission to use 
this material. (This may be dealt with by requiring 
course attendees to have a source license.) Be¬ 
cause the usenix tutorials fall outside of the “fair 
use” clause of the U.S. copyright code, the same 
rules apply for supplementary papers or reports. 

Finally, your proposal should also include a 
summary of your previous teaching or lecturing 
experience, as well as a couple of references (one 
or two people who have seen you teach that we 
can contact). These may be your students, su¬ 
pervisors, or colleagues. 

Remember, this is just a proposal, so nothing 
you submit will be cast in concrete. You may later 
decide to change some ordering of materials, or 
we may suggest some changes. You needn’t worry 
about getting it perfect the first time around. 
What we are trying to do is get a very solid feel 
for what you are offering. You must sweat out 
some of the details, but needn’t go too crazy over 
them. 

The tutorial schedule is currently filled for 
the Summer 1991 conference in Nashville, so all 
proposals will be for the Winter 1991 conference. 
The tutorial schedule for that conference needs to 
be decided upon by June 1991, so proposals for 
tutorials should arrive by May 15, 1991. Please 
send your proposals to dvk@usenix.org, or by 
physical mail to: 

Daniel Klein 

usenix Tutorial Coordinator 

5606 Northumberland 

Pittsburgh, PA 15217-1238 
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Report from EurOpen 

Alain Williams 

<addw@phcomp.co.uk> 

Name Change from EUUG 

The EUUG was formed in 1976 after meetings 
between the Dutch and British UNIX user groups. 
These groups were largely made up of program¬ 
mers of a predominantly academic background 
since these were the people who used UNIX in 
those days. 

How times have changed! The majority of 
UNIX users are no longer academics and few are 
progammers. Most of today’s UNIX users do not 
care how their computer works, as long as it does 
what they want and at a good price. UNIX has 
evolved and become a solid foundation upon 
which applications can be built. The traditional 
command line 1 was first hidden by numbered 
menu systems, and later by mouse-driven GUIs. 
Standards committees were formed to properly 
define what services and interfaces should be pro¬ 
vided. New operating systems that conformed 
(more or less) to these standards appeared; no¬ 
tably Chorus, Mach, AIX/OSF and Amoeba. 

As EUUG evolved, more and more members 
came from commercial companies, first from sys¬ 
tems houses who saw it as a future computing 
base, and then their technical customers who 
started to use UNIX in their businesses. The orig¬ 
inal two member nations grew ever more rapidly 
to the present total of twenty countries repre¬ 
senting a total of over 4,300 registered individuals 
and organisations. 

With the coming of perestroika and the easing 
of license restrictions to the Eastern Bloc, several 
Eastern European countries have recently joined 
us. 

UNIX is not even called UNIX any more, but 
it is an Open System, as it has opened the com¬ 
puting industry up to real competition. 

It was felt that the euug should also change 
its name to reflect these changes and to be able 


1. which was only considered unfriendly by people who 
were used to something else. It however became an 
easy catch phrase amongst journalists who, having 
learned a little about MS-DOS, believed that they thus 
understood computing. 


to cater to and represent the users of open systems 
in Europe. Thus on October 24, 1990 at the Au¬ 
tumn conference in Nice, France the “European 
UNIX Systems User Group” became the “Euro¬ 
pean Forum for Open Systems” or EurOpen for 
short. 

Troms0 Conference 

EurOpen is holding its Spring conference in 
Troms0, Norway from May 20 to 24, 1991. The 
conference will concentrate on Distributed Open 
Systems in Perspective. In addition to an overview 
of the issues involved in the design of distributed 
Open Systems the conference will address prob¬ 
lems encountered and solutions found when dis¬ 
tributed open systems are employed. 

The three day conference with a commercial 
exhibition on Open Systems will be accompanied 
by technical tutorials on Monday and Tuesday, 
followed by the main conference from Wednesday 
to Friday. 

If you would like to know more, please con¬ 
tact the EurOpen secretariat at the address given 
below. 

Publications 

A list of publications that are available from 
EurOpen follows with an order form. 

We also plan to offer the publications of all 
EurOpen national groups though the EurOpen 
secretariat. 


EurOpen Dublin 

Autumn ’83 

$ 4 

Proceedings Nijmegen 

Spring ’84 

$10 

Cambridge 

Autumn ’84 

$10 

Paris 

Spring ’85 

$10 

Copenhagen 

Autumn ’85 

$20 

Finland/Sweden 

Spring ’87 

$40 

Dublin 

Autumn ’87 

$40 

Munich 

Spring ’90 

$40 

Nice 

Autumn ’90 

$50 

Directories 



European E-Mail directory, 1st edition 

$36 

European E-Mail directory, 2nd edition 

$40 


All prices include postage and handling. 


12 


January /February 1991 



;login: 16:1 


ORDER FORM: 

This page may be photocopied for use. Please print! 

Name:_ 

Company name:_ 

Address:_ 


E-mail address: _._ 

I would like to order the following: 


I enclose my payment in the sum of_and understand that a receipt will be sent. 

I would like to receive membership details of EurOpen: YES/NO 
Payment may be made in one of four ways: 

1. By UK Cheque or Bankers Draft, made payable to EurOpen and drawn on a UK bank. 
Eurocheques are acceptable, but each cheque must be for £100 or less. 

2. By Direct Payment to EurOpen’s bank. Please tell your bank that you will pay all charges so that 
EurOpen will receive the full amount due. 

The Bank of Scotland Account Number: 00613997 
61 Grassmarket Bank Sort Code: 80-31-50 

Edinburgh 
Scotland EH1 2JF 

3. □ by VISA □ by ACCESS/EUROCARD/MASTERCARD 

Name as it appears on the card (block capitals)_ 

Address of card holder_ 


Card Account No + _________ Date of Expiry 

Signed_Date_ 


The prices include air mail to Europe, but surface to the rest of the world. 

Please send the order form or any requests for information to: 

EurOpen euug@EU. net 

Owles Hall Tel: + 44 763 73039 

Buntingford Fax: +44 763 73255 

Hertfordshire SG9 9PL 
U.K. 
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Work-in-Progress Report: LISA 

Bjorn Satdeva 

bjorn@sysadmin.com 

During the Large Installation Systems Ad¬ 
ministration Conference held in Colorado Springs 
in October 1990, there were three presentations 
during the Work in Progress session. Below are 
short descriptions of each. 

1. A Configurable, Transportable Login and 
Shadow Package for UNIX 

Steve Simmons (scs@iti.org) 
and John F. Haugh II 

Goal 

• A version of login, passwd, etc. that is 
highly secure, and very configurable 

• For BSD and System V 

a Development environments are System 
V.3, SunOs, Ultrix, and Xenix 

• For TCP/IP and standalone 

• Will maybe include Kerberos 

Configurable features 

• Issue 

• hushlogin 

• error logging 

• mold environment-file 

• getpwent() suite 

• pre-user hook 

• last login 

• pre-shell hook 

• long (16 chars) passwd 

• ATT and ITI aging 

• Account expiration (respected everywhere) 

Specific Utilities 

• login 

• passwd 

• chfn 

• chsh 

• vipw 

• pwconv 

• pwunconv 

Status 

• Shadow2 posted 

• Shadow3 in alpha/beta now 

• Shadow3 porting to BSD in process 

• Shadow4 remerge 


IV Conference 


Future Benefits 

• Very general library 

• Detailed documentation 

2. Extending the UNIX File System in Time 
and Space 

John P. Linderman 

(jpl@allegra.tempo.nj.att.com) 

We have taken advantage of the impressive 
storage capacity of optical disks to build an NFS 
file system that extends an ordinary mag disk unix 
file system in time and space. The time dimension 
involves storing multiple versions of files and di¬ 
rectories. Daemons identify changes in the mag 
disk file system, and deliver new versions to the 
optical store. The changed files and directories do 
not replace older ones. Instead, they provide an¬ 
other version, in effect adding a time dimension 
to the file system. Past versions can be referenced 
by simply appending a time qualifier to the file 
name. Thus, 

aiff file fileailOct 

can be used to compare the most recent version 
of a file (the default when no time qualifier is 
present), with the version that existed on October 
11. This “3 dimensional” file store is a standard 
NFS file system. There are no kernel changes. No 
special commands are necessary to “copy back” 
past versions of files, and normal unix commands 
behave as you would expect without recompila¬ 
tion or relinking. Directories, as well as normal 
files, are available, so it is possible (and common) 
to do 

cd subdirectorya)15aug 

grep LISA * 

to search a subdirectory as it existed in the past. 
The default time qualifier is inherited from the 
current directory. 

The time qualifier is not part of the file names 
as stored, so the shell has no “wildcard” charac¬ 
ters in the time dimension. However, the 3dls 
command can be used to expand names in the 
time dimension. For example, 
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grep user '3clls orgchart' 

will look for a user in all available versions of the 
org chart. 

The file system has virtually eliminated the 
need for operator assisted file recovery. If a user 
destroys a file, it can be restored by simply doing 

cp file /usr/homedir 

The normal unix file system permissions al¬ 
low users to restore their own files without having 
unintended access to the files belonging to others. 

In addition to this time dimension, the system 
also extends mag disk file systems in a space di¬ 
mension. Mag disk file systems can be mounted 
so that file names containing a time qualifier are 
automatically fielded by the 3 dimensional file 
server. Administrators can employ a “truncate” 
command to free the mag disk blocks occupied by 
a file. Read references are transparently satisfied 
by the optical system, and write references cause 
files to be copied back to the mag disk, where they 
can be modified. By truncating files that are read 
only or that are seldom referenced, the effective 
capacity of the mag disk is enlarged enormously. 

3. AIX/370 Interface to VM Accounting 

Lenny Silver , Cornell University Systems 

Programming (len@cornellf.tn.cornell.edu) 

This describes an implementation of resource 
accounting on our AIX/370 system, using the ex¬ 
isting VM accounting running on CP/CMS/MVS. 
Our task is to provide reasonable accounting re¬ 
ports from unix without trying to reinvent Cor¬ 
nell accounting, which runs on MVS. 

In what follows, the word account is used to 
mean an amount of money with a certain purpose. 
Userids are joined to accounts, again with a cer¬ 
tain amount of money. Joins and accounts have 
expiration dates. 

A snapshot of all Cornell accounts that are 
enabled for AIX is sent nightly to eagle, our main 
AIX node. The nightly snapshot consists of three 
files: accounts, joins, users. 


Nightly reports are also returned from eagle 
to VM accounting showing resource usage per 
join. 

The nightly snapshot is processed on eagle by 
the program acm. acm creates three btrees in 
/etc/account: accounts, joins, and users. These 
files are recreated every night, acm also maintains 
a permanent file of correspondences between ac¬ 
counts and numbers, /etc/account/numbers. 

If a new userid occurs, acm creates and con¬ 
figures a login directory and creates a password 
file entry for this userid. 

Kernel modifications are necessary to imple¬ 
ment an account in AIX. In addition, Cornell has 
enhanced login and passwd to create and validate 
a default account. 

A library libbt.a has been created with all 
routines needed to access the files in /etc/account. 
This includes low level routines, such as insert a 
new record in a btree, as well as higher level 
routines such as list all joins for a userid. 

This work has been done in conjunction with 
an IBM AIX Joint Study. 


Executive Office Staff Changes 

In December, the Association hired Douglas 
Nielson to be its Deputy Executive Director. 
Doug was formerly the office manager at mt Xinu, 
Inc. Prior to that he worked with the marketing 
department of the University of California Press, 
and has also held various positions in library sci¬ 
ence and public relations. Doug will be working 
closely with Ellie in directing the day-to-day op¬ 
erations of the Berkeley office, as well as assisting 
her in a variety of other tasks including budget, 
publications, and special projects. 
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Long-Term Calendar of UNIX Events + 


1991 Mar 13-20 

CeBIT 91 

Hannover, Germany 

1991 Mar 21-22 

*Symp. Distrib. Multiproc. Sys. 

Atlanta, Georgia 

1991 Mar 26-30 

AFUU CNET 

Paris La Defense, France 

1991 April 

NCR Unix User Group 

San Antonio, Texas 

1991 April 15-19 

IEEE 1003 

Swissotel, Chicago, IL 

1991 April 22-25 

*USENIX C++ 

Washington, D.C. 

1991 Apr 22-26 

DECUS Muenchen Symposium 

Hannover, Germany 

1991 May 6-10 

DECUS 

Atlanta, GA 

1991 May 9 

APP/OSE Users Forum 

NIST, Gaithersburg, MD 

1991 May 15-17 

Multi-User C Show 

UniForum, Toronto, Canada 

1991 May 15-17 

IEEE TCOS Cptr Workstations 

Falmouth, MA 

1991 May 20-24 

EurOpen 

Troms0, Norway 

1991 Jun 10-14 

USENIX 

Opryland, Nashville, TN 

1991 Jun 16-19 

Sun User Group 

Atlanta, GA 

1991 July 

JUS Symposium 

JUS, Tokyo, Japan 

1991 Jul 8-12 

IEEE 1003 

Santa Clara, CA 

1991 Jul 15-17 

UKUUG 

Liverpool, UK 

1991 Aug 5-8 

Interex 

San Diego, CA 

1991 Autumn 

*Large Installation Sys. Admin. 


1991 Sept 10-12 

European Sun User Group 

NEC, Birmingham, UK 

1991 Sept 16-20 

EurOpen 

Budapest, Hungary 

1991 Sept 24-27 

AUUG 

Sydney, Australia 

1991 Oct 

ISO/IEC JTC1 SC22 WG15 

Sweden 

1991 Oct 10-11 

Multi-User C Show 

UniForum, Montreal, Quebec, Canada 

1991 Oct 21-25 

IEEE 1003 


1991 Oct 30 

IEEE CS SCC/SAB 

Nashville, TN 

1991 Nov 14 

APP/OSE Users Forum 

NIST, Gaithersburg, MD 

1991 Nov 

JUS UNIX Fair 

Osaka, Japan 

1991 Dec 9-11 

Sun User Group 

San Jose, CA 

1991 Dec 9-13 

DECUS 

Anaheim, CA 

1991 Dec 16-18 

UKUUG 

Edinburgh, UK 

1992 Jan 13-17 

IEEE 1003 


1992 Jan 20-24 

USENIX 

San Francisco, CA 

1992 Jan 20-24 

UniForum 

San Francisco, CA 

1992 Spring 

EurOpen 

Jersey, UK 

1992 Apr 20-24 

IEEE 1003 


1992 May 4-8 

DECUS 

Atlanta, GA, 

1992 Jun 8-12 

USENIX 

San Antonio, TX 

1992 Jun 21-24 

Sun Users Group 

Washington, DC 

1992 Jul 13-17 

IEEE 1003 

Alaska 

1992 Autumn 

EurOpen 

Amsterdam, Netherlands 

1992 Sept 8-11 

AUUG 

Melbourne, Australia 

1992 Oct 19-23 

IEEE 1003 


1993 Jan 25-29 

USENIX 

San Diego, CA 

1993 Mar 15-18 

UniForum 

San Francisco, CA 

1993 Jun 21-25 

USENIX 

Cincinnati, OH 

1994 Jan 17-21 

USENIX 

San Francisco, CA 

1994 Mar 23-25 

UniForum 

San Francisco, CA 

1994 Jun 6-10 

USENIX 

Boston, MA 


+ Compiled with the assistance of Alain Williams of EurOpen and Susanne Smith of Windsound Consulting. 
*USENIX Workshops and Mini-Conferences 
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Report on ISO/IEC JTC1/SC22/WG15 (POSIX) 

October 23-26, 1990 

Orcas Island, Washington, U.S.A. 

Dominic Dunlop 

The Standard Answer Ltd. 

domo@tsa.co.uk 


Introduction 

Are you a regular reader? I hope so, as this 
report on the October meeting of Joint Technical 
Committee 1, Subcommittee 22, Working Group 
15, colloquially known as the ISO POSIX working 
group, seems to be particularly replete with buzz¬ 
words, acronyms and jargon. I try to explain these 
as I encounter them, but since usenix and Eur- 
Open (formerly euug) have been sponsoring me 
to produce these reports for almost two years 
now, some of the explanations are buried in pre¬ 
vious editions. For now, you will just have to bear 
with me; I will take time to explain how we ar¬ 
rived at the current state of affairs in a future 
column. This one concerns itself mainly with 
where we are headed, and with the difficulty of 
actually getting there. 

As far as ISO is concerned, posix, like Gaul, 
is divided into three parts. Forget all those pro¬ 
liferating ieee 1003 posix working groups (eight¬ 
een of them at the last count), and just think of 
three standards: IS9945-1 for a definition of the 
services offered by the operating system; 
IS9945-2 describing the shell and tools; and 
IS9945-3, system administration. 

The good news is that you can now buy the 
first edition of the first of these 1 . The bad news 
is that all three iso standards projects are running 
into scheduling difficulties. And there is even 
more bad news if you are an Ada™ fan: in order 
to ease its own difficulties, the iso posix working 
group has put a serious road block between your 
favourite language and an international standard 
defining how you may use it to access posix ser¬ 
vices. Why did we do this, and why don’t we feel 
bad about it? Read on... 


1. From the ieee, which has agreed to print the world’s 
first combined ieee/ansi/iso standard—on iso standard 
A4 paper. Ask for ieee Std. 1003.1:1990 It will cost you 
$52.50 if you are an ieee member, $75.00 otherwise. 
Add $5.00 for surface mail to Europe. In the U.S.A., 
call (800) 678-ieee; elsewhere, +1 908 981 1393. IEEE 
accepts “major credit cards”. 


9945-3—System Administration 

As you are probably aware, the ieee P1003.7 
working group on system administration has de¬ 
cided that current UNIX administrative tools and 
practices are sufficiently obsolete, inadequate and 
diverse that they are not worth standardizing. 
Instead, the group has elected to define a new, 
object-based administration scheme which views 
a system as a collection of objects to be admin¬ 
istered, and a network of systems simply as a 
larger collection of such objects. 

Although this approach grafts neatly onto the 
network administration work which has been go¬ 
ing on in the Internet and Open Systems Inter¬ 
connection (osi) communities, it will be a while 
before it produces any results. As we shall see in 
connection with 9945-2, when ISO delegates re¬ 
sponsibility for the development of a standard to 
another body, as it has done with the POSIX stan¬ 
dards, it likes the documents to be in a relatively 
stable state before they are submitted for use as 
iso Working Documents (wes). 1003.7 thinks that 
it will have something suitable for iso to start 
work on by 1992. 

Unfortunately, ISO rules state that, unless a 
project has resulted in a we within three years of 
authorization, the authorization stands in danger 
of automatic withdrawal. The only way out is for 
a national standards organization participating in 
the development of the standard to call for a vote 
on project continuation before the time limit ex¬ 
pires. The time limit for the production of a draft 
for 9945-3 has almost been reached, with no pros¬ 
pect of the deadline being met. 

It seems inevitable that the twenty-four coun¬ 
tries participating in the iso posix project will be 
formally balloted as to whether they think that the 
authorization to develop a system administration 
standard should stand, despite the missed dead¬ 
line. This is not a particularly big deal: an ex¬ 
amination of iso’s information technology stan¬ 
dardization work reveals that around twenty 
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percent of projects miss one deadline or another, 
(osi standards have a particularly poor track 
record.) 

Nevertheless, it is embarrassing when the 
managerial finger is pointed at one’s own project. 
Already, the special pleading has started; the 
SC22 Advisory Group, which makes recommen¬ 
dations on policy issues to the iso programming 
languages subcommittee, has suggested that “in 
general, standards developed within SC22 are 
larger and more complex than most others, and 
the time limits given in JTC1 directives 2 ... will 
therefore often be too short.This may be 
true—although work elsewhere in iso suggests 
that SC22 has no monopoly on large projects. 
However, it seems to me that the time limits given 
by the directives cannot reasonably be relaxed; if 
no visible progress has been made on a project 
after three years, those involved had better be 
given an opportunity to ask themselves why, and 
to consider whether they wish to continue giving 
their support. I am sure that, if it comes to a vote, 
the result will favour the continuation of the sys¬ 
tem administration project. Just don’t hold your 
breath waiting for the final standard. 

9945-2—Shell and Tools 

The shell and tools standard is not crowding 
a deadline as closely as is system administration, 
but is not clear of trouble either. At least we have 
a committee draft (CD — one step beyond a we), 
corresponding to draft 9 of 1003.2, but have failed 
to move it forward to the next stage, a Draft 
International Standard (dis). According to the 
directives, we have four years in which to do this 
before serious questions get asked, and the iso 
directorate makes a decision about project ter¬ 
mination. Although our progress to date has not 
been rapid, we have some time in hand. 

Our first attempt to register the 1003.2 draft 
as a DIS failed. (See my report on WG15’s Paris 
meeting^.) The problem was that, while the tech¬ 
nical content of a dis is supposed to be essentially 
the same as that which will appear in the recent 
International Standard (is), we all knew that the 
content of 1003.2 was still undergoing rapid and 


2. The rule book which guides our every move is The 
JTC1 Directives. It is surprisingly readable, and very 
clear on general principles and procedures, but seems 
to be intentionally vague on many details. 


sometimes radical change. There was no way that 
draft 9 could have been accepted as a Dis. (The 
u.s. National Institute for Standards and Tech¬ 
nology (nist) ultimately decided not to base a 
Federal Information Processing Standard (fips) 
on draft 9 for similar reasons.) 

Draft 11 (or later) of 1003.2 will be passed to 
ISO in January, 1991 (or later), in the hope that 
it can be registered as a revised CD, and will stand 
more chance of clearing the remaining hurdles 
which separate it from is status. Until this hap¬ 
pens, we have a situation described by one nor¬ 
mally restrained working group member as a 
“pure disaster”. We are about to suggest that 
draft 6 of 1003.2A, the User Portability Exten¬ 
sion, due early in 1991, be registered as a pro¬ 
posed draft amendment (pdam) to 9945-2, with¬ 
out having a stable document to amend 3 ! 

In this situation, somebody may ask us why 
we don’t just roll the amendment into the next, 
hopefully more stable, version of the CD. The 
practical answer to the question is that the ieee 
is treating 1003.2 and 1003.2A as two separate 
documents, and we would prefer to do the same. 
How much weight such an argument might carry 
with the iso secretariat is another question. 

9945-1—Operating System Interface 

Now that 9945-1:1990 operating system in¬ 
terface definition is an international standard, in¬ 
ternational standards work on posix has reached 
the end of its beginning. What do we do next? The 
problem is that we are spoiled for choice. An 
embarrassing number of the 1003 projects repre¬ 
sent extensions to, or restatements of, the services 
described in 9945-1: 

1003.1A: A 1003.1 extension draft, covering 
tweaks such as symbolic links, will be 
ready for us early in 1991. We shall 
probably vote to register it at our next 
meeting. 

1003.1LI: (Provisional name.) This is the 
language-independent specification of 
the services defined by the current 
1003.1 standard in terms of their C lan¬ 
guage interface. It may be ready in late 


3. The upe to 1003.2 describes interactive utilities for 
program development, supplementing 1003.2’s descrip¬ 
tion of the non-interactive tools used in shell scripts. 
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1003.1C: 


1003.2: 


1003.4: 


1003.4A: 


1003.4B: 


1003.5: 


1003.6: 


1991, provided that enough IEEE vol¬ 
unteers can be found to work on it. 
(Provisional name.) Building on the 
definition provided by 1003.1LI, these 
C bindings will correspond exactly to 
the C interface defined by the current 
1003.1. Again, a draft may be ready 
late in 1991. 

The shell and tools standard defines C 
language interfaces to regular expres¬ 
sion handling, filename expansion, ar¬ 
gument string parsing and more. Ar¬ 
guably, these belong in 9945-1. They 
are also candidates for language- 
independent specification. 

We have requested that the current 
draft of 1003.4 4 , real-time extensions 
to the portable operating system inter¬ 
face, be registered as a pdam to 
9945-1. The first international posix 
standard has only just hit the streets, 
and already we are trying to amend it! 
The 1003.4 working group considers 
that draft 5 of its threads (lightweight 
process) standard will be ready for sub¬ 
mission to iso at the same time as 
1003.4. As yet, we have made no de¬ 
cision to accept it. 

This is simply a language-independent 
specification for the services described 
by 1003.4 in terms of their binding to 
the C language. The ieee working 
group does not know when it will be 
ready, and we don’t yet know when we 
shall be ready to accept it. The two 
issues are connected: if we say we want 
work on it to be accelerated, it is likely 
to be ready more quickly. 

The Ada description of the portable 
operating systems interface is well on 
its way to becoming an ansi/ieee stan¬ 
dard. Expect to see it in 1992. Sadly, 
for reasons explored below, 1003.5 is 
unsuitable as a basis for an ISO stan¬ 
dard. 

The security extension to the operating 
system interface will be ready for us to 
have a look at in January of 1991, al- 


4. That is, the draft current at the time that the iso 
secretariat requests ansi to provide a document for 
circulation to SC22 and WG15 as a prelude to calling 
a vote on registration. This will be draft 10, or, more 
probably, draft 11. 


though it will be a while before it is 
mature enough for pdam registration. 
1003.8: Transparent file access, that is, trans¬ 

parent access by a process hosted on 
one system to files held by another, is 
making rapid progress after narrowing 
down its goals until it identified an 
achievable target. The ieee working 
group expects to have a document suit¬ 
able for ISO review by mid-1991. 
1003.9: The fortran 5 bindings to the operating 

system interface definition are written 
in a manner which is more to iso’s taste 
than the Ada description of the same 
services, and will be ready for iso re¬ 
view in late 1990. However, we have 
elected not to bring it forward to in¬ 
ternational standards status in the near 
future. Again, our reasons are ex¬ 
plored below. 

1003.16: This recently-authorised IEEE project 
aims to produce C language bindings to 
some future language-independent 
specification of the POSIX operating sys¬ 
tem interface. Like Ada and fortran, 
it is tied up with the whole issue of 
language independence. 

I wrote last time about the background to the 
language independence debate^ 21 . Further discus¬ 
sion and a useful bibliography can be found in^. 
iso strongly favours language-independent service 
specifications, but very few people in the U.S. are 
interested in writing them. ISO has delegated de¬ 
velopment responsibility for posix to ANSI, which 
in turn has passed the buck to the ieee— an or¬ 
ganization which ISO cannot officially talk to or 
aid. As a result, ieee is saddled with a problem 
which it is ill-equipped to solve. 

At our Paris meeting, we signalled our dis¬ 
appointment with the ieee’s progress towards a 
language-independent specification for posix by 
refusing to register drafts of 1003.4, .5, and .9. 
The list above shows that we have relented on 
1003.4, but have left .5 and .9 out in the cold. 

The difference between this meeting and the 
last is that they are now definitively out in the 
cold, and will not be let into the iso process until 


5. Obscure style note: one is supposed to refer to the 
proposed 1990 version of the language as Fortran; to 
older versions as fortran. 1003.9 is a binding to FOR¬ 
TRAN 77. 
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we are very close to having a language-indepen- 
dent version of IS9945-1 for them to bind to. 
Here, with a few interpolations in square brack¬ 
ets, is the resolution that says why: 

Language-Independent Specifications: 

Whereas, SC22 AG [the advisory group men¬ 
tioned above in connection with 9945-2] has 
recommended that the production of 
language-independent specifications and lan¬ 
guage bindings for posix be carried out in 
such a way that it does not delay the stan¬ 
dardization of the C language bindings 111 
[Thank you. That’s just what most of us 
wanted to hear.]; and 

The production of a language-independent 
specification corresponding to IS9945- 
1:1990 and subsequent C language-based 
amendments, together with a C language 
binding to that language-independent speci¬ 
fication, is required by the Division of Work 
Item JTC 1.22.21 [A Division of Work Item 
is an ISO mechanism for splitting an autho¬ 
rised project into several sub-projects]; and 

The production of further language bindings 
to the language-independent specification 
corresponding to 9945-1:1990 as subse¬ 
quently amended is ultimately desirable; and 

WG15 considers that “thin” language bind¬ 
ings (which must be read in conjunction with 
a service definition) are suitable candidates 
for standardization, but “thick” bindings 
(those which incorporate a service definition 
duplicating and possibly conflicting with the 
service definition provided by another stan¬ 
dard) are not [The terms “thin” and “thick” 
derive from the number of pages in the doc¬ 
ument in question. 1003.5 is a “thick” bind¬ 
ing, so we do not like it much; 1003.9 is a 
“thin” binding, but to the C language spec¬ 
ifications of the current 1003.1]; 

Therefore , JTC1/SC22/WG15 requests the 
U.S. member body [ansi, which in turn gets 
the IEEE to do the work] to provide a sched¬ 
ule for the delivery to WG15 and SC22 of 
9945-1-related documents which is subject to 
the following constraints (listed in order of 
precedence, highest first): 

1. The incorporation or development of 

language independence features shall not 


be on the critical path(s) for the production 
of C language-based documents; 

2. The ultimate goal is the production of an 
extended [extended, that is, by 1003.4, 
1003.6, 1003,8...], language-independent 
9945-1 and accompanying “thin” binding 
to the C language at the earliest possible 
date; 

3. Every attempt shall be made to observe 
JTC1/ISO rules on the bringing forward of 
amendments, etc., with the need to seek 
waivers being highlighted if this appears 
necessary in order to satisfy the constraints 
above; 

4. Language bindings, other than those for 
the C language, shall not be brought for¬ 
ward to WG15 or SC22 for any purpose 
other than review and comment before the 
language-independent 9945-1 has been 
registered as a Dis; and 

5. Where possible in the light of other con¬ 
straints, C language-based documents shall 
include an informative annex setting out a 
language-independent definition of the ser¬ 
vices defined by the normative body of the 
document. 

The schedule shall identify timeframes for at 
least the following document circulation and reg¬ 
istration milestones: 

1. “Thick” C bindings for amendments to 
9945-1:1990; 

2. Language-independent specifications 
corresponding to 9945-1:1990 and subse¬ 
quent amendments; 

3. “Thin” C bindings to language-indepen¬ 
dent specifications corresponding to 9945- 
1:1990 and subsequent amendments; 

4. A combined language-independent 
9945-1 and accompanying “thin” C bind¬ 
ing to the services that it defines; and 

5. “Thin” bindings for further languages to 
the whole of the combined language- 
independent 9945-1, or to supersets or 
subsets of the services which it defines. 

I hope that your eyes have not glazed over: 
public statements of policy get convoluted and 
legalistic at this level, but all of this verbiage 
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actually represents a concise description of the 
problem and what we see as a route to its solu¬ 
tion 6 . For the first time, this tells the ieee exactly 
what type of document that the iso working group 
wants to see, and in which order: 

a. C-based standards first. 

b. Language-independent standards with a 
corresponding “thin” C binding second. 

c. “Thin” (and only thin) bindings to other 
languages no sooner than b. 

d. Examples of language-independent spec¬ 
ifications (as opposed to definitive standards 
for them) any time that IEEE can manage to 
produce them. 

e. All in accordance with iso rules on the 
publication of amendments and revisions to 
standards (we hope). 

There was some understandable objection 
from the U.S. to “micro-management”—if we 
were defining so many goals, constraints, and 
checkpoints, why didn’t we just write the schedule 
ourselves? The answer is that there is still quite 
a lot of flexibility allowed: the ieee has a dozen 
or more documents to bring forward, and it can 
decide on the ordering and the dates. We just 
want to know when those dates are, and to dis¬ 
allow certain orderings. 

The amount of resources that the ieee can 
muster to work on language-independent speci¬ 
fications determines when step b can occur. Does 
anybody want to volunteer to make it sooner than 
1995? 

The real victim of our newly-defined policy is 
Ada. It is clear that there will be an ansi/ieee 
standard for an Ada definition of the posix op¬ 
erating system interface, probably in two years. It 
is now equally clear that, because it will be a thick 
binding, this standard cannot move forward to 
gain international status. There may ultimately be 
a thin Ada binding to a future language- 
independent 9945-1. It may define an interface 
identical to that defined by 1003.9, but probably 
not. We could face the unpalatable prospect of an 
iso standard which differs from the corresponding 
ansi standard. 


6. Although I could be biased: I drafted the resolution. 


Why don’t we feel too bad about this? Well, 
it seems that the main requirement for an Ada 
posix standard comes from within the U.S. 1003.5 
will fill this need, and we should not seek to delay 
it. The need for an international standard in this 
area is less clear, but we have now given clear 
guidelines on the form that it should take, just as 
soon as anybody wants to develop it. 

That said, it is clear that we still have much 
to learn about... 

Coordination 

One aim of the ieee and iso posix projects 
is that the international standards that result 
should be identical to the corresponding U.S. 
standards. Another is that ISO publication should 
not lag behind IEEE publication by too long. 
IS9945-1 is a benchmark in both cases: by dint of 
the IEEE agreeing to print for both organizations, 
content is identical, and publication is simulta¬ 
neous. This will be a hard act to follow, not least 
because there are thousands of pages of ieee 
drafts in the pipeline, all of which must undergo 
international review before they can even start 
going through the three-stage ISO mill which 
grinds documents into international standards. 

It has been the policy of the ieee not to 
submit documents to ISO until they reach their first 
ieee ballots—that is, until they are reasonably 
mature and complete. In view of our rejection of 
1003.2 draft 9 because we did not consider it 
mature enough, this seems like a prudent ap¬ 
proach. The trouble is that by the time the ieee 
considers a document mature, it is also likely to 
be difficult to change in any significant manner. If 
we had earlier visibility into the subject matter 
and approach of the ieee’s work, we could com¬ 
ment on its future acceptability to ISO. For ex¬ 
ample, we could have suggested that 1003.5 pur¬ 
sued a “thin” rather than a “thick” binding. 

To try and get out of the hole that we have 
dug for ourselves, we have requested “early vis¬ 
ibility” of IEEE draft standards. Seeing standards 
when they are young and small will also aid in¬ 
ternational understanding of the larger more ma¬ 
ture versions when they appear. 

OSCRL 

The posix project bears a growing similarity 
to an ancient yet still inhabited castle: some parts 
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are old and crumbling; others require constant 
repair if they are to remain habitable; and, all the 
time, new walls, doors, and towers are being 
added. 1003.7 even seems to be demolishing a few 
unsightly outbuildings. Coordination should en¬ 
sure that nobody builds a wall where someone 
else wants a door. Or a whole new tower when all 
that was needed was a new entrance to an existing 
one, as happened in the case of 1003.5. 

No castle is complete without a ghost, and 
posix has one: oscrl— Operating System Com¬ 
mand and Report Language. Started in the early 
eighties, it was (to simplify to an almost indictable 
extent) an attempt to define a common Job Con¬ 
trol Language for the large computers of the day. 
It found a home in SC21, which looks after osi, 
just before it became apparent that UNIX was 
going to become the “open” operating system of 
choice. Ahead of its time, the oscrl project at¬ 
tracted a small but enthusiastic following, but, as 
the years went by, work tailed off. It was all but 
non-existent by the time the iso posix project was 
set up. However, it is ISO policy when starting new 
projects to examine any related work which it may 
have undertaken, and the search turned up OSCRL 
as covering topics to be addressed by 9945-2 and 
9945-3. 

SC21 welcomed the chance to pass the 
project to another group, and we reluctantly 
agreed to take it over. Then the iso central sec¬ 


retariat lost all the paperwork. (It is a fact of life 
that all bureaucracies lose paperwork.) We had an 
excuse to prolong oscrl’s spell among the un¬ 
dead, provided that we could put up with the 
periodic howls from its (few) proponents. 

These howls recently resulted in a polite sug¬ 
gestion from the SC22 AG that we should do 
something to quiet them. That something might 
be the massaging of the existing material (if it can 
be found) in to a Technical Report — a type of 
document which few people ever read, and the 
production of which is discouraged by ISO. But a 
TR may just be the sort of headstone that OSCRL 
lacks. We will be trying to nail down the coffin lid 
at our next meeting, which takes place in the 
Netherlands from 14th-17th May, 1991. 
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Book Review 

lex & yacc 

by Tony Mason and Doug Brown 

(O’Reilly & Associates, 1990, ISBN 0-937175-49-8, $24.95, 218 pages) 

Reviewed by Vern Paxson 

Lawrence Berkeley Laboratory 


lex and yacc are two of the more powerful 
UNIX tools, especially suited for complex text ma¬ 
nipulation and compiler-writing. They are com¬ 
plicated enough to warrant a book-length refer¬ 
ence, which has been lacking. Sadly, lex & yacc 
is not even close to being suitable. The book’s 
flaws are numerous and pervasive. 

Clearly the book has not been proofread. It 
is riddled with typos and incorrect examples. It 
also needs editing. Terms and symbols are used 
before they are explained. Promised explanations 
and examples fail to appear. Established termi¬ 
nology is confused (“token” is used to refer to 
non-terminals, individual input characters, and 
the contents of symbol tables). The text is padded 
with replications: a 29-line example is repeated 
verbatim, with 2 new lines added. 50 lines of code 
are replicated exactly, bugs and all. The index is 
missing relevant entries and contains incorrect 
page numbers. 

It is painfully clear that the authors are not 
experts with lex and yacc , either, for they miss 
numerous subtle and not-so-subtle points in their 
use. There is no discussion of how to redirect lex 
input; their comments on yywrap completely miss 
its main use; non-existent flags are discussed; the 
division between what’s best done in the scanner 
and the parser is greatly confused. Numerous 
comments are appropriate only for toy scanners 
(“Much of the lex overhead is of a fixed size”; 
“the visual model of the finite state machine is an 
invaluable debugging tool”). Escape characters 
are missing or used when not needed. Throughout 


the text the pattern #*20$ is used to match com¬ 
ments, yet the correct definition is #.*$. The 
authors compound this error by treating com¬ 
ments as tokens to be returned to the parser, 
though their grammars have no rules for dealing 
with the tokens, so even if the correct pattern 
were used, each comment would result in a syntax 
error! Furthermore, these errors persist in the 
code the authors distribute with the book—they 
never tested the code! One wonders about the 
authors’ proficiency with C, too: they use bzero to 
make a string empty rather than string[0] =’O’. 

Finally, the book lacks depth. The running 
examples are somewhat contrived and fail to ad¬ 
dress many common problems. There are no 
parse tree diagrams to explain grammar ambigu¬ 
ities, no advice on how to remove ambiguities 
once detected, no discussion of building abstract 
syntax trees, no explanation of the precedence of 
regular expression operators. Practical problems 
such as scanning C comments or strings with em¬ 
bedded escape sequences, or getting error line 
numbers correct, or using the scanner to aid in 
parsing ambiguous grammars, are simply not dis¬ 
cussed. 

All in all the book is too simplistic, errone¬ 
ous, and confusing to be of much value to either 
the novice or the experienced user. 

The reviewer, Vern Paxson, is a computer scientist 
at Lawrence Berkeley Laboratory, a computer science 
graduate student at U.C. Berkeley, and the author of 
flex, a freely redistributable version of lex. 
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An Update on UNIX-Related Standards Activities 

Jeffrey S. Haemer 

Report Editor, USENIX Standards Watchdog Committee 


Report on IEEE 1003.0: POSIX Guide 

Kevin Lewis <klewis@gucci.dco.dec.com> 
reports on the October 15-19, 1990 meeting in 
Seattle, Washington: 

When 1003.0 left off in July, we were wres¬ 
tling with guide content, profile structure, and 
self-discipline (which can be hard to find via con¬ 
sensus). Not only were the first two resolved, but 
we decided not to leave until we had resolved 
each of the fifteen issues in our issue log. This 
negated the original plan to walk through the 
document section by section, but to no one’s sor¬ 
row. (Some members applauded the decision.) 

Outstanding and resolved issues included 
federal vs. national standards, level of detail in 
write-ups, exhaustive vs. non-exhaustive listing of 
standards, descriptive vs. prescriptive approach, 
target audience(s), and document flow (being able 
to follow each element of the posix open system 
environment through each chapter easily). The 
group was euphoric over breaking through these 
logjams. 

Mid-week we discussed the mock ballot. 
Jayne Baker, from 1003.5, who is also partici¬ 
pating in our group, gave an excellent presenta¬ 
tion on the "Do’s & Don’t’s” of the mock ballot 
process. It became readily apparent from our dis¬ 
cussion that we had been naive on mock ballots. 
We will discuss a detailed plan at the January 
meeting. I now see mock balloting on draft 11, 
which would become available around March, 
1991. Stay tuned for more on this. I will be de¬ 
veloping a mock-ballot group listing, and will wel¬ 
come active participants. This will probably hap¬ 
pen before the January meeting. 

Let me finish by summarizing some key ac¬ 
tions and decisions. Guide content and profile 
structure were resolved to the unanimous satis¬ 
faction of the group. The group agreed that the 
guide’s content should be divided into two parts, 
corresponding to two audiences: 

• For the “unwashed masses” of profile writ¬ 
ers, those not doing standards develop¬ 


ment, the balloted portion of the guide will 
contain guidelines. 

• For the benefit of profile writers writing 
formal functional profiles, we agreed to 
place formal rules in an appendix. The 
group also sent a resolution to the tcos-ss 
sec recommending that some activity be 
taken up (be it in or out of the ieee) to 
develop a posix core profile. Coincidentally 
(honestly, it truly was coincidental), the sec 
approved a posix Platform Environment 
Profile par for 1003.1. Just between you 
and me, I think 1003.1 is the right forum for 
the work outlined in our resolution. 

Let me end by repeating my earlier request. 
If you are interested in becoming a part of our 
mock ballot group, please contact me by phone 
(202)383-5017 or e-mail klewis@gucci.dec.com. 

Report on IEEE 1003.4: Real-time 
Extensions 

Rick Greer <rick@ism.isc.com> reports on the 
October 15-19, 1990 meeting in Seattle, Wash¬ 
ington: 

Real-time Ballot Recirculation 

The real-time (dot 4) ballot, originally mailed 
nine months ago, will get its first recirculation in 
November. The primary reason for the long delay 
in resolving ballot objections has been technical 
reviewing or a lack thereof. Reviewers were as¬ 
signed to each major section of the draft even 
before it went to ballot, but some sections are still 
completely unchanged from the balloted draft. 
This is supposed to be fixed by the November 
mailing. 

Pthreads Goes to Ballot 

Meanwhile, the pthreads document (dot 4a) 
is due to go out to ballot in December, so Jeff still 
has a 50/50 chance of winning his free beer. Per¬ 
sonally, I think the pthreads draft is going out in 
better shape than its predecessor and will prob- 
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ably require fewer recirculations. On the other 
hand, it may face a major stumbling block on its 
way to becoming a standard that base real-time is 
not yet required to deal with: Language Inde¬ 
pendent Specification. While the base document 
was grandfathered out of the us requirement, it 
is not clear that pthreads will be awarded the same 
privilege. 

Ironically, a language-independent specifica¬ 
tion for pthreads could do more to accelerate its 
acceptance as a standard than to impede it. A 
couple of highly contentious areas of the draft 
(thread-specific data and certain aspects of thread 
cancellation) are C-language specific. The ratio¬ 
nale has been updated to note this fact, but some 
working group members feel that many potential 
objections could be avoided if the text of the draft 
proper explicitly noted the language-specific na¬ 
ture of these contentious features. Unfortunately, 
there seems to be no way of doing this, short of 
providing a true language-independent specifica¬ 
tion. 

Signals (Again!) 

One often hears the argument that the vo¬ 
luminous changes between one draft and the next 
show that attempting to standardize thread be¬ 
havior is premature. There is enough substance to 
this complaint that it cannot be dismissed out¬ 
right. In fact, one reason for balloting now was to 
use the balloting process to impose some sort of 
change control on the document itself! What some 
critics don’t realize is that most semantic changes 
in the last year have all centered around a single 
issue: signals. The latest draft is no exception to 
this rule; it introduces yet another signal com¬ 
promise . 

I’m not completely happy with the latest sig¬ 
nal compromise, but it has one major advantage 
over all previous attempts to unite opinion on this 
issue. The new compromise recognizes that the 
basic contention is not so much technical (i.e., 
per-thread vs. per-process signal delivery 
schemes) as philosophical. One camp feels 
strongly that traditional POSIX signal behavior 
should be extended in some way so that all the 
P1003.1 interfaces have some meaning in a multi¬ 
threaded environment (with some argument over 
just what this meaning should be). Others feel 
that asynchronous signal processing is completely 


inappropriate in a multi-threaded program and 
would rather see an entirely new interface (sig- 
wait()) to deal with the problems that asynchro¬ 
nous signals were originally designed to solve 
(with some argument about just what these prob¬ 
lems are). To satisfy the “preserve the Dot One 
interface” camp, the document that goes to ballot 
will include precise, per-thread signal semantics, 
the details of which are bound to raise numerous 
ballot objections. To satisfy the “sigwaitQ only” 
camp, the Dot One interfaces to these semantics 
can be completely disabled by a run-time switch, 
the utility of which is bound to raise numerous 
ballot objections. Thus, the new signals proposal 
has all the earmarks of a good compromise: Ev¬ 
erybody agrees that it solves the problem but 
nobody likes it. 

One other realization to come out of the 
debate was that the same points have been argued 
over and over for four meetings. We concluded 
that the rationale behind the pthread signal be¬ 
havior specification was inadequate and needed to 
be totally rewritten. Unfortunately, we didn’t re¬ 
write it at the meeting, although people were 
assigned to do this work before the draft goes to 
ballot. It remains to be seen whether the new stuff 
that goes out to ballot will be any easier to un¬ 
derstand than the old stuff. I just received a copy 
of the new signal rationale with a request to proof 
it, so I’ll have an opinion soon. 


Rate Monotonic Scheduling 

One reason that pthreads did not go to ballot 
after the July meeting was that some of the mul¬ 
tiprocessor folks (Dot Fourteen) felt that the 
thread scheduling section was overspecified, lean¬ 
ing heavily towards uni-processor, fixed-priority 
scheduling. (The counterargument was, “Of 
course it leans heavily towards uni-processor 
fixed-priority scheduling: That’s what we’re trying 
to standardize!”) Those who objected the loudest 
were charged with coming up with specific 
changes to the draft that would correct the prob¬ 
lems envisioned by the mp experts (e.g., high 
overhead in mp implementations because of the 
need to maintain uni-processor scheduling invari¬ 
ants and the general preclusion of novel mp so¬ 
lutions to resource allocation problems). To their 
credit, they did this without changing any of the 
previously specified scheduling interfaces or up- 
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setting any of the uni-processor semantics implied 
therein. What they did was to introduce a couple 
of new terms and concepts: “processor-allocation 
domain” and “thread-contention scope.” They 
went on to say that when the processor-allocation 
domain is greater than one (i.e., when you’re 
running on a multiprocessor), the effect of setting 
a thread’s contention scope is implementation- 
defined (i.e., mp schedulers are free to ignore the 
contention scope). Everyone seems to think this 
leaves the door open to any sort of multi¬ 
processor resource allocation scheme that is likely 
to appear in the future. (Can anyone supply a 
good counterexample?) 

As long as the thread scheduling chapter was 
still in flux, however, others felt that this would 
be a good time to introduce an additional inter¬ 
face in support of rate monotonic scheduling. RMS 
is used in some real time systems to deal with, 
among other things, the problem of priority in¬ 
version 1 . This met with widespread disapproval. 
There were three major arguments for not in¬ 
cluding an rms interface in the draft: 

1. RMS is not common practice, so it shouldn’t 
yet be standardized. One would think that the 
history of pthreads itself is enough to illustrate the 
futility of this line of reasoning. After all, how 
many commercial implementations of a particular 
feature are necessary before said feature becomes 
“common practice” — especially when the very 
lack of a standard interface is a force preventing 
widespread acceptance of the feature in the first 
place? 

2. Given that rms is primarily a real-time 
tool, it should be specified as part of dot 4 rather 
than dot 4a. It is ironic that by sending dot 4 to 
ballot without a threads chapter the work group 
has effectively weakened arguments for including 
real-time features in the pthreads standard. And 
yet, pthreads was specifically introduced as a 
means of solving asynchrony problems in real¬ 
time environments! 

3. RMS can and should be supported by add¬ 
ing new scheduling attributes, rather than new 
interfaces. While I agree that rms should be sup¬ 
ported via new scheduling attributes, it is not at 

1. Priority inversion occurs when a high priority task 
waits for resources controlled by a low priority task 
which is, in turn, prevented from executing by a third 
task whose priority lies somewhere in between. 


all clear to me that it can be. The real problem 
here may be a deficiency in the pthreads attribute 
mechanism rather than the lack of a specific rms 
interface. 

At any rate, the technical reviewers can ex¬ 
pect ballot objections from the proponents of rms 
and should be thinking about ways to accommo¬ 
date them. 


Report on 1003.6: Security Extensions 

Ana Maria De Alvare <anamaria@sgi.COM> 
reports on the October 15-19, 1990 meeting in 
Seattle, Washington: 

Just when you thought it was safe ... 

Hello, readers! I’ve been away for a while, 
but I’m now back in the P1003.6, posix Security 
Extensions battles. [Editor: And we’re glad you 
are.] So much for socializing; on to the October 
meeting. 

IEEE 1003.6 continued its work on Discre¬ 
tionary Access Control (dac), Mandatory Access 
Control (mac), privileges, and audit. It also spent 
half a day in a consortium with the networking, 
administration, and security groups addressing ar¬ 
eas where the four intersect. 

Balloting 

The group currently plans to mock-ballot 
Draft 8. Group consensus was to push the stan¬ 
dard forward and get serious about producing a 
document that we can agree on. The meeting 
must have been akin to Congress’s recent budget 
struggle. 

The group will address written comments on 
draft 8 at the January meeting, clean up the draft, 
and send draft 9 out to balloting members. Only 
IEEE or Computer Society members can ballot, so 
if you want your objections to count as official 
votes, join now. As with all ieee standards, 75% 
acceptance will be needed to pass. 

During the ballot phase, the group will focus 
on answering ballot objections, and creating both 
a language-independence interface and a test 
suite. 
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Objections, objections 

At the October meeting, we discussed 
P1003.2 commands, cleaned up the dac mecha¬ 
nism and privileges sections, redefined the audit 
interface, and filled gaps in mac. I will discuss 
each section separately. 

P1003.2 

We produced two lists from the current 
P1003.2 draft. One contains commands that need 
clarification or need to address security: mailx , 
mv, and cd. Jeremy Epstein, from trw, will write 
up our concerns about this list and send them to 
P1003.2. 

The other list is for our own subgroups, 
which will examine them to decide which are 
relevant to their subgroup. The commands that 
need security input are: cd, chmod, cp, find, get - 
conf, id, kill, chown, chgrp, In, Ip, Is, mailx, mv, 
nohup, rm, rmdir, stty, and test. In addition a new 
command is needed for doing pax with security; 
6pax was a name suggested. [Editor: No, no. The 
precedent is set: pax9L] At the January meeting, 
we will move on to the User Portability Exten¬ 
sion, P1003.2a. 

One issue raised by the collaborators that 
produced these lists was that each subgroup in 
P1003.6 has created a get/set function for its par¬ 
ticular area. After considering whether the group 
should consolidate all get/set functions into one or 
add options to existing commands, the whole 
group agreed to stay with the original design: a 
get/set function per area. The justification was 
that this design allows a flexible interface and 
implementation, and makes it easy to add func¬ 
tionality without changing existing commands. 

Mandatory Access Control (mac) 

The MAC group feels their portion of the 
document is almost ready for mock ballot but still 
needs to address multi-level directories, especially 
mlmkdir (create a multi-level directory) and ml - 
rmdir (remove a multi-level directory). 

The group agreed on the treatment of opaque 
objects in the standard, and decided the standard 
should support variable length objects. They 
looked at the P1003.2 commands and inserted 
their information in chapter 5 of P1003.6 and 
decided to make information labels optional. 


MAC brought a pair of open issues to the 
whole group: 

1. Should we use options or positional pa¬ 
rameters: 

setlabel -x label file 

or 

setlabel label filel 

We agreed on options. 

2. At the plenary session, we agreed to make 
all P1003.6 interfaces optional. Thinking this 
through, mac asked what wording to use when 
one area depends on another. In particular the 
group wants to address what happens in the ab¬ 
sence of least privilege. 

Everyone agreed that we need consistent 
wording, and we will look at proposals next meet¬ 
ing. 

Discretionary Access Control (dac) 

The dac group spent all their time cleaning 
and preparing their rationale for mock ballot. The 
scheme they’ve come up with for Access Control 
Lists (acls) is interesting, but a little complicated. 

acls contain four entries: use. OBJ, mask- 
_ obj, group, obj, and other, obj. Three of 
them, user.obj, mask.obj, and other.obj, 
correspond directly to the owner, group and other 
classes respectively. Is -l still displays the file type, 
such as ‘d’ for directory, followed by three bits 
apiece of “owner”-class, “group”-class, and 
“other”-class information. Modifying an ACL en¬ 
try modifies the corresponding file class permis¬ 
sion bits, and vice-versa. 

So far, so good. But what’s the fourth entry, 
group, obj? Well, it’s also related to group ac¬ 
cess (hence, the name), and often, but not always, 
contains the same value as mask. obj. Here’s the 
algorithm for checking read access based on gid: 
If the effective GID or any supplementary process 
GiDs match the gid of the file then: 

1. If mask, obj doesn’t give read access, read 
access is denied. The check stops here. 

2. If MASK. OBJ gives read access, the system 
checks to see whether the group, obj grants read 
access. 
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• If group_ OBJ grants read access and 
matches the process GID, access is granted. 

• If group_ OBJ denies read access and the 
acl contains other group_ obj entries that 
match either the effective GID or any of the 
GiDs associated with that process, then it 
checks all of them until it finds one that will 
grant access. 

• If none of them grants access, access is 
denied. 

Audit 

For the second time the audit group has 
agreed to follow the structure of the X/Open audit 
document. They are planning to merge X/Open 
with P1003.6 draft 7. They settled on: event types, 
headers, information per event type, generic 
structure, and function call interface. 

They have not addressed any audit analysis 
definitions or interfaces for audit analysis. 

Privileges 

The privilege group went through draft 7 
cleaning up descriptions, writing the rationale for 
the design, and writing examples on how privi¬ 
leges are assigned and inherited through exec() 
(including a drawing). 

The major dispute was about the two flags 
associated with executable file privileges: allowed 
and forced. Members from AT&T, IBM, and Se- 
cureware claimed security systems did not require 
allowed privileges. 

The close interrelationship of the forced and 
allowed flags create a complex mechanism to de¬ 
termine how privileges are granted. Let me ex¬ 
plain. The forced flag lets system administrators 
grant a process certain privileges unconditionally. 
It provides backward compatibility with setuid 
programs. 

The allowed flag, as originally stated, spec¬ 
ifies that a new process image shall be permitted 
a privilege if the parent process image has allowed 
that privilege to be inherited. When allowed is set, 
forced is used to specify whether a new process 
image shall unconditionally possess that privilege. 

The group agreed that although the interre¬ 
lationship between these flags is counter-intuitive, 
the allowed flag provides a useful way to let sys¬ 


tem administrators constrain the privileges that a 
process can inherit, and should remain in the 
standard. 

The new algorithm for determining if a pro¬ 
cess inherits a privilege begins by checking 
whether the forced flag is on, or the allowed and 
inheritable flags are both on. If either of these is 
true, the permitted flag will be set (i.e., the pro¬ 
cess gets the privilege); otherwise, the permitted 
flag will be cleared (i.e., the process doesn’t get 
the privilege). 

Networking, Administration, and Security 
Consortium 

The group met for half a day. The main focus 
was to identify areas where the groups overlap. 
Five were identified: 

1. P1003.6 resources that need to be admin¬ 
istered; 

2. Additional security mechanisms; 

3. P1003.7 (System Administration) objects 
and their security attributes; 

4. P1003.6 areas that can affect networking; 

5. Distributing mechanisms. 

Summary 

P1003.6 current and future plans are: 

• January 1991 — Internal mock ballot on 
Draft 8 

• February 1991 — Send Draft 9 to ballot 

• End of 1991 — Write the language- 
independence interface and insert it as an 
annex to the balloting during recirculation 

1991 (during balloting process) — Write test 
assertions 

Register recirculation draft as a CD (Com¬ 
mittee Draft in the international area). 

Reorganize P1003.6 to fit the international 
standard’s style: dis 9945-1 (lis), dis 9945-1 (C- 
Bindings), dis 9945-2 (command area). 
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Report on 1003.11: Transaction 
Processing 

Elliot J. Brebner 

<brebner@s5000. RS VL. UNIS Y S. COM> 
reports on the October 15-19, 1990 meeting in 
Seattle, Washington: 

Who are we? 

The POSIX Transaction Processing Profile 
working group (P1003.ll, or Dot Eleven) is doing 
what it sounds like — standardizing various as¬ 
pects of transaction processing in a POSIX envi¬ 
ronment. We’re influenced by work going on in 
X/Open’s xtp Working Group, but we’re not 
simply waiting for X/Open’s xtp Working Group 
to produce documents to be blessed. The group 
is maintaining a needed critical mass, and if 
X/Open does little to publish by the middle of next 
year, will be ready to move on alone. 

Profiles 

A key accomplishment to date is the push, 
along with the other profile groups, to have the 
coordination and Profile Coordination Group 
Meetings under .0 (Bob Gambrel’s) leadership. 
The result should be a more uniform set of posix 
Profiles whose quality is improved via shared ef¬ 
fort. 

The Ad Hoc Profile Coordinating meetings 
were well attended and profitable. (As was ours 
— Dot Eleven had 16 active participants at the 
Seattle meetings.) We expect to see more Coor¬ 
dinating meetings in January in New Orleans. 
Meanwhile, we are starting to flesh out our Trans¬ 
action Processing Profile in the POSix-AP-Profile 
style that we agreed to in those meetings. Our 
working group doled out work assignments to 
review other P1003.n documents in search of 
needed functions. We also eagerly await the ex¬ 
ample profile that Don Terry has promised, the 
posix Platform Environment Profile being done in 
1003.1, which the sec has now approved a par for. 

Carl Hall’s draft input to the P1003.0 Guide, 
describing the P1003.ll tp Profile, was edited in 
detail. The revised draft was submitted to Dot 
Zero following the meeting, and should appear 
(with proper figures) in the next Guide draft. 


APIs 

As expected, the subject of new par(s) for TP 
APi(s) came up. At the Danvers meeting, we 
agreed on a key point: that 1) although Dot 
Eleven should continue to work on distributed 
transaction processing, transaction processing 
need not be distributed, and 2) we need to define 
some standard API for the substantial existing 
practice. One API, between applications and 
transaction management services, should allow 
applications to start transactions, and then end 
them with either a commit or a roll-back. To do 
this, we need a new par. 

A second possible API would specify the con¬ 
trol of resource managers by a transaction man¬ 
ager 1 , but the group considers this a system in¬ 
terface, not an api. For now, we and Dot Zero 
have jointly agreed to call this a System Program¬ 
ming Interface (spi). Work in this area would also 
require a separate par. We put off deciding 
whether to submit one or both pars pending a 
better understanding of exactly what would be in 
the api/spi, confident that we’re gaining that un¬ 
derstanding rapidly as a byproduct of the profile 
work. Mark Carges’ presentation on the X/Open 
ap-tm primitives provided further understanding 
of X/Open’s work in this area. 

If you received copies of the X/Open Prelim¬ 
inary Specification, Distributed Transaction Pro¬ 
cessing: The xa Specification (dated April, 1990) 
at Salt Lake, you should by now have received a 
mailing with instructions on how to comment on 
the document. If you have not, or you’re an active 
Dot Eleven participant and would like a copy, 
please let me know. I will forward a request for 
a complimentary copy to X/Open. X/Open also sells 
copies at a nominal cost. X/Open has set the clos¬ 
ing of the External Review period as January 
1991, but comments are welcome earlier. 

Language Independence 

Stephen R. Walli <walli@osmcll.gm.hac.com> 
reports on the October 15-19, 1990 meeting in 
Washington state: 


l.The subject of the X/Open Preliminary Specification: 
The XA Interface. 
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1. Programming Language Independent Specifi¬ 
cations and POSIX 

What is LIS? 

A Language Independent Specification (lis) 
is an iso requirement for making POSIX an inter¬ 
national standard, and the IEEE Technical Com¬ 
mittee on Operating Systems, Standards Subcom¬ 
mittee (tcos-ss) has agreed to provide the posix 
standards in this format 1 . 

An LIS is a rigorous functional description of 
operating system interfaces not tied to any pro¬ 
gramming language syntax or semantics. Each 
base Lis description is accompanied by a set of 
language binding descriptions 2 . This approach — 
a base Lis standard plus multiple language binding 
standards — has been used in the past for spec¬ 
ifying communications and graphics standards. Its 
advantage is that it lets programming languages 
bind to the abstract descriptions in a natural way; 
its disadvantage is that groups specifying a service 
interface must abstract that service from its his¬ 
torical language context. 

Mundane as this sounds, if you aren’t in¬ 
volved with the posix working groups, you may 
not know that Lis is emotionally charged. For 
starters, Lis affects most POSix-related working 
groups. Base standards groups (1003.1, 1003.4, 
1003.6,1003.8,1224) must all provide Lis versions 


1. A quick standards-taxonomy lesson: 

The tcos-ss’s executive committee (sec) is re¬ 
sponsible for co-ordinating the IEEE posix Working 
Groups’ production of draft IEEE standards, and for 
bringing them both to ansi nationally, and to iso, 
internationally. While ansi, the American National 
Standards Institute, creates U.S. standards, iso and the 
IEC are responsible for the highest level of open systems 
standards; iso committees and working groups guide 
standards to international acceptance. ISO/iec Joint 
Technical Committee 1 (jtci) is responsible for infor¬ 
mation processing standards. Subcommittee 22 (SC22) 
of JTCI is responsible for programming-language- 
related work, and Working Group 15 (WG15) has the 
specific responsibility to define the criteria IEEE POSIX 
must meet to become an international standard (such 
as lis). 

Here, we will refer to the ieee/ansi effort as 
posix, and to the WG15 effort as iso posix. 

2. Don’t confuse the language binding with a program¬ 
ming language standard. A standard C binding for 
posix includes things like C function prototypes for the 
posix system calls: this is separate from the ansi or iso 
standards for C itself. 


of their documents. Language binding groups 
(1003.5, 1003.9) must bind to the Liss. All in all, 
POSIX participants run the extremes from those 
eager to use Liss to those vehemently opposed to 
all that it requires of their documents. 

Some Areas of Debate 

“Thick or thin?” One current, often conten¬ 
tious, debate revolves around language binding 
philosophy. While some argue that bindings 
should be “thick” stand-alone documents, which 
contain both syntax and semantics, others envi¬ 
sion bindings as “thin” syntactic descriptions of 
how the language binds to the Lis with pointers 
to the Lis for any semantic description. The Ada 
working group has chosen the thick road; the 
fortran working group, the thin. 

Though thick bindings might seem more us¬ 
able for developers, they have two potential prob¬ 
lems. First, duplicating semantics risks differences 
of interpretation. Second, document synchroni¬ 
zation complicates the inevitable base revisions. 

“ Scheduling” Scheduling and resource prob¬ 
lems create another area of tension. Because 
working group chairs all want to move their draft 
documents forward quickly, an Lis requirement 
strains the already overworked, all-volunteer 
working groups. 

Yet another problem is scheduling the work 
of interdependent working groups. Real-time, se¬ 
curity, and transparent file access (1003.4, 1003.6, 
and 1003.8) are all extensions to 1003.1 and all 
part of the same iso document (9945-1). 1003.5 
and 1003.9 are Ada and fortran bindings for 
1003.1. Coordinating these interdependent doc¬ 
uments — all at different points in their devel¬ 
opment and language independence — creates an 
of ten-noticeable tension. 

Status 

To aid the POSIX Lis effort, Paul Rabin 
(sometime 1003.1 snitch) and I were asked to 
produce a set of methods and guidelines. 

The model is based on work done by iso/sc22 
Working Group 11 (wgii), which is responsible 
for defining common language-independent data 
types and procedure-calling mechanisms stan¬ 
dards. Unfortunately, although the WGi I work is 
directly related to posix lis, it hasn’t yet pro- 
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duced iso standards and posix needs the stan¬ 
dards immediately. This poses another scheduling 
problem. (Incidentally, WGII and WGI5 realize 
their work is interrelated and keep each other 
informed of their progress.) 

Before the October posix meetings, the 
Methods document had been refined to draft 2 
and used successfully to produce an Lis for section 
4 of 1003.1-1990. The Real-time group also used 
earlier drafts to produce an experimental Lis 
translation of large part of 1003.4/D9, but will 
probably not move ahead until the C-based draft 
finishes balloting. Meanwhile, P1003.9 (fortran 
77 Binding to 1003.1) is about to start balloting, 
and P1003.5 (Ada Binding to 1003.1) is balloting, 
but both were developed from a C-based stan¬ 
dard. . 

Seattle, October 15-19, 1990 

The October posix meetings saw much dis¬ 
cussion of lis issues. Official discussions were 
concentrated in the Birds-of-a-Feather (bof) ses¬ 
sions and the sec meetings. 

The BOFs 

posix meetings schedule regular lis bofs to 
discuss language bindings, lis methods, and other 
technical issues. October saw two: one Tuesday 
afternoon and another Thursday afternoon. Paul 
Rabin chaired both. 

The first was dedicated to work up to the 
present. With a comment or two added for clar¬ 
ification, here were the issues raised: 

* As always, a few people questioned why we 
were doing the work. What purpose does it 
serve? These concerns were directed to the 
sec, which sets lis policies and schedules; 
justification for the work is an sec policy 
issue. 

* Some voiced concern about the Methods 
document’s stability. Before the next P1003 
meeting, it will go through one more major 
revision. Some take this to mean it is cur¬ 
rently unusable, but I think this is unhelp¬ 
ful. Working groups must use this docu¬ 
ment to improve it, and holding back only 
delays the process. At this point, the basic 
format will probably not change; future re¬ 
vision will extend the document based on 
our experiences with this draft. 


• “What exactly does ISO want?” was a com¬ 
mon question. No one wants to get all the 
work done only to face an iso rebuff. Al¬ 
though this valid question has sometimes 
delayed lis work, by the end of the two 
weeks of posix meetings both the sec and 
iso had endorsed our direction. 

• There is great interest in using lis methods 
to help create base assertions for a binding. 
(Some feel this is the only reason for doing 
an lis.) There is no question that it would 
help if bindings groups could use such work 
to help prepare the test assertions that the 
sec has placed as another addition to the 
standards effort. 

The second bof was dedicated to lis work in 
progress. We reviewed the Methods document, 
explaining the document format, the scope, the 
model, and the guidelines to Lis and language¬ 
binding writers. Though the document needs fur¬ 
ther review, there was general agreement with the 
approach. 

The SEC meetings 

lis consumed a fair amount of the October 
sec meetings. 

Many now believe that Lis work is blocking 
C-based standards documents from reaching the 
industry. Recently, the SC22 Advisory Group 
(SC22 ag) recommended that the posix lis work 
not delay standardization of C-based documents. 
A resolution advanced at the first sec meeting to 
relax the lis requirements at the IEEE level was 
tabled until the second meeting, and an investi¬ 
gative sub-committee was formed. 

At the second meeting, the SEC resolved that 
C-based base standards that go to ieee ballot after 
October 18, 1990 but before a 1003.1 lis goes to 
ballot, must have an lis before balloting ends. 
Documents that go to ballot after a 1003.1 LIS 
goes to ballot must have an Lis to go to ballot. 
Finally, once lis 1003.1 is an iso Draft Interna¬ 
tional Standard, all documents must enter IEEE 
ballot as an lis or as a language binding to an lis. 
Before this, the lis may take the form of an 
annex. Although WG15 only asked that such an¬ 
nexes be informative (non-binding), the resolu¬ 
tion requires a normative (binding) annex to en- 
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courage detailed review 3 . The resolution 
grandfathers in Shell and Tools (1003.2) and 
Real-time (1003.4), but Real-time already has a 
separate par for the Lis. 

There is great pressure on 1003.1 to complete 
a 1003.1-1990 Lis quickly. Though 1003.1 lacks 
resources to devote to this, many cite the lack of 
a 1003.1 Lis as reason to delay starting other Lis 
work. Addressing this, the 1003.1 working-group 
chair proposed a second resolution, which also 
passed. The resolution: 

1. endorses the Methods document and its 
use and the tracking of future revisions, 

2. encourages everyone to help 1003.1 com¬ 
plete their Lis, and 

3. asks 1003.3 (Test Methods) to help classify 
1003.1 test assertions as language-independent or 
C-specific. 

All this set the stage for the ad hoc WG 15 lis 
meeting. 

Orcas Island, October 22-26, 1990 

WG15 met the following week. With only 
about twenty attendees, the meeting was man¬ 
ageably smaller. 

Not a standards-drafting organization, WG15 
is concerned with such issues as internationaliza¬ 
tion and co-ordination with other standards. 
Long-range, the group’s goal is to make ieee and 
iso standards identical and cleanly integrated with 
other iso standards. “Interoperability between 
standards” was a frequently heard phrase, and we 
were glad for the expertise that the Europeans 
present brought from their current EC integration 
work. 

The first two days of WG15 saw an ad hoc Lis 
status review meeting, which involved roughly 
half the WGI5 participants. Happily, the wgii 
Convener attended and provided useful insight 
into their current efforts. Once again, Paul Rabin 
was the chair. 

The ad hoc group reviewed the issues and 
concerns that the IEEE POSix working groups had 
raised, and made a list of recommendations. The 


3. After the meeting we realized that the sec's reso¬ 
lution was silent on C-language bindings to the Lis 
annexes, but the ad hoc WG15 Lis meeting the follow¬ 
ing week fixed this, deeming it an implicit requirement. 


full session later discussed these and had the draft¬ 
ing committee prepare formal resolutions, which 
were passed on the last day. 

Resolutions included these: 

• wgi 5 supports the Methods document’s 
scope and direction. Specifically, this doc¬ 
ument says that Liss do not require formal 
methods, and that interoperability between 
applications written to different language 
bindings is desirable, but not required. (Ra¬ 
tionale and discussion for the Methods doc¬ 
ument’s scope is provided in both ^ and 

pm 

• Future Lis and C bindings need not exactly 
match IEEE 1003.1-1990; requiring this 
would prevent necessary bug fixes and ad¬ 
denda. (But reviewing the WG15 resolu¬ 
tions^, I can’t find this written down.) 

• Base lis standards should specify conform¬ 
ance requirements for language bindings. 
The Methods document still requires an 
addition here. It is to be hoped that wgi i’s 
work in this area will prove helpful. 

• wgi 5 asked the ieee to provide a schedule 
for the delivery of the Lis work, including 
in that request the constraints on the sched¬ 
ule and the expected items for delivery. (A 
complete discussion of this resolution can 
be found in ^.) 

• The motivation for the resolution on Lis 
scheduling says: 

WG15 considers that thin language bindings 
(which must be read with a service definition) 
are suitable for standardization, but thick bind¬ 
ings, which incorporate a service definition du¬ 
plicating and possibly conflicting with the ser¬ 
vice definition provided by another standard, 
are not; 

This sends a clear message to the thick/thin 
language bindings debate. 

Putting it all together 

How does all this come together and where 
is it going? Here is my opinion — not my em¬ 
ployer’s, not Pioo3’s, not wgis’s. 

Everyone official seems to endorse the Meth¬ 
ods document’s scope and method. 

The Methods document is stable and usable. 
Draft 3 will be upwardly compatible with Draft 2, 
and will have the same format. 
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At its next meeting, with everyone interested 
in the outcome, 1003.3 will investigate the subject 
of us test assertions. A high percentage of test 
assertions may prove language independent. 

The thick Ada binding will continue to come 
forward as is at the ieee level, but will need to 
slim down to become an international standard. 
If no one is interested in an international stan¬ 
dard, no thin binding may be needed. Document 
synchronization and standards revision issues with 
thick standalone national language bindings prob¬ 
ably won’t be felt for some time. The issue of 
writing test assertions for the binding looms and 
will spark much debate in the January meetings. 

There are document synchronization issues 
between TCOS and ISO, which affect the coordi¬ 
nation of C-based documents, Lis and language 
bindings, made worse by the time frame differ¬ 
ences between the TCOS and iso standards pro¬ 
cesses. Scheduling this large, complex project 
staffed by overworked volunteers is a thorny 
project management issue. 

It would be great if the SEC built and pub¬ 
lished a proper schedule, itemizing all of the in¬ 
dividual work items, (base C-based draft docu¬ 
ment, LIS annex, C-binding annex, bindings) and 
dependencies. This would clearly convey to all 
parties the work to be done, the interdependen¬ 
cies and the rough time frames. Indeed, this is 
what WG15 has requested. 

The SEC has already outlined what needs to 
be done to enter/exit IEEE ballot. WG15 merely 
wants to see project milestones, dependencies, 
and a schedule. This will certainly spark inter¬ 
esting debate in January. 

P1003.1 will stay in the pressure cooker. The 
sec’s encouraging resolution has no teeth, so will 
help little. Some have mentioned October 1991 as 
a date to expect completion of a 1003.1 Lis, with 
a C binding by the following spring. This seems 
to be a reasonable date based on the current 
involvement with Lis to date. It would certainly 
be helpful if people contacted Paul Rabin (at the 
address below) to help move this work forward 
more quickly. Although groups cannot complete 
their liss without a 1003.1 Lis, they will continue 
working productively, following the model of 
Real-time. 


For more information 

Paul Rabin is managing an Lis mailing list. 
Messages for distribution to the whole list 
should be sent to posix-lis@osf.org (or 
uunet!osf.org!posix-lis). Requests for updates 
to the list should be sent to posix-lis- 
request@osf.org. 
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Report on Name Space/Directory 
Services 

Mark Hazzard <markh@rsvl.Unisys.com> 
reports on the October 15-19, 1990 meeting in 
Seattle, Washington: 

Introduction 

I’d like to introduce a new POSIX work group: 
Name-Space and Directory Services (ns/ds). A 
par has been submitted to and approved by the 
tcos sec, so the working group will be official by 
the New Orleans meeting in January. The group’s 
number will be 1003.17. 

You don’t have to be clever to detect a du¬ 
ality in our name. We are trying to solve two 
separate but related issues. 

Name Space 

POSix has several name-spaces: the file sys¬ 
tem, processes, user and group IDs, and others 
(with more on the way). Consider, for a moment, 
just the process name-space. Today, when I want 
to know something about processes, I use ps , 
which typically shows a one- to five-digit 
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process-id for each process in the left-hand col¬ 
umn of its output. I get a unique value for every 
process I’ve asked about. This works because I 
only care about local processes — processes 
“within” the specific kernel I’m talking to. 

Suppose that it becomes commofiplace to run 
concurrent processes on several kernels. It would 
be useful to ask for the status of all the processes 
I own with a single command. A natural way to 
do this would be to extend ps to solicit and display 
status information on global as well as local pro¬ 
cesses. The name-space for the process ID would 
need to be extended to identify a process uniquely 
within the universe (or some reasonable subset of 
it). 

This is the name-space problem in a nutshell. 
The group discussed it at length but we were not 
sure how to proceed. We found ourselves ping- 
ponging between the name space issue and the 
“other half” of our charter, Directory Services 
(DS). 

Directory Services 

We are a networking group, so to us directory 
means something like dns or X.500, not “a file 
that contains file entries.” Specifically, we intend 
to provide an “API to a directory service, including 
but not limited to X.500 functionality.” After 
some soul searching, the group has decided to 
focus on the DS aspect of our charter, given the 
limited resources we’ve been able to muster. 

Name-space and directory services are re¬ 
lated. Directory functions allow users to read, 
write, list, compare, etc. global objects and their 
attributes. Objects are defined within a name- 
space and share basic characteristics: syntax, se¬ 
mantics, authority, and uniqueness (they can exist 
within only one name-space). It’s logical to con¬ 
clude that the name-space for an object must be 
defined before it can be put into the directory 
information base. This has already been done for 
many osi objects (ccitt X.520/521) 1 . 


1. OSl/cciTT have defined the objects they want X.500 
to manage, so we don’t have to. These are specified in 
CCITT X.520, Selected Attribute Types, and in CCITT 
X.521, Selected Object Classes. 


Base Documents 

One of the first activities the group under¬ 
took was to identify candidates (if any) for a basis 
specification for the DS API. We turned up a pair 
of candidate specifications that had been coop¬ 
eratively developed by the X/Open XNET group 
and the X.400 API Association. Together, the two 
specifications, xom (Object Management) and 
XDS (Directory Services), form a single api to 
directory services The group evaluated their 
functional content against the requirements and 
agreed to accept xds and xom as the basis for the 
DS API. 

You may be wondering why two specifica¬ 
tions are required to define one API. A little his¬ 
torical perspective might help. The collaboration 
mentioned above actually developed a trio of 
specifications. The one I haven’t listed defines 
interfaces to (you guessed it) X.400. They decided 
to define a general purpose api (xom) for man¬ 
aging OSI objects, which would work for both 
X.500 and X.400 api (and possibly others). 

Our group is currently in the process of 
“POSixizing” xds. This means reworking xds to 
conform to POSix style, content, and format re¬ 
quirements. Improving xds’s readability and com¬ 
prehensibility is another goal. Providing a 
language-independent binding and test assertions 
will require a major effort. 

“But what about xom?” you ask. We were 
curious too. Since we plan to share xom with at 
least one other TCOS group (P1224 - X.400), we 
thought we’d better ask the Distributed Services 
Steering Committee, which oversees all the 
networking-related groups. It answered, “Keep 
XOM a separate specification and cut a new par for 
it. The PAR will be submitted by the P1224, but 
the work will be shared between ns/ds and 
P1224.” 

Summary 

So, that’s what ns/ds is working on. We’ve 
got a first cut at a table of contents, and have 
hacked our way through a language-independent 
binding for at least one function call. We’re trying 
to get a lot of work done between cycles, and we 
expect the next few meetings to be “roll up the 
sleeves” sessions as we work our way through the 
documents. 
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Local User Groups 

The Association will support local user groups by doing a mailing to assist the formation of a 
new group and publishing information on local groups in ;login At least one member of the group 
must be a current member of the Association. Send additions and corrections to login@usenix.org. 


CA - Fresno: the Central California UNIX Users 
Group consists of a wwcp-based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

brent@CSUFresno.edu or csufresibrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 875-8755 

csufreslgordon (209) 298-8393 


CA - Irvine: the UNIX Users Association of 
Southern California meets the 2 nd Monday of each 
month. 

Rich Bergstedt, AT&T (714) 727-5231 

8001 Irvine Center Dr., Suite 224 
Irvine, CA 92718-2900 

UUASC Information Line (714) 727-5232 


CO - Boulder: the Front Range UNIX Users Group 
meets monthly at different sites. 

Steve Gaede gaede@sda.com 

Software Design (303) 444-9100 

& Analysis, Inc. 

1113 Spruce St., Ste. 500 
Boulder, CO 80302 


FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 


FL - Fort Lauderdale/Miami: The South Florida 
UNIX Users Group meets the 2 nd Tuesday of each 
month. 

Tony Vincent, John McLaughlin (305) 776-7770 
{sun,novavax,gould) !sunvice!tony 
j mclaughlin@sun. com 

John O’Brien (305) 475-7633 

gatech!uflorida!novavax!john 


FL - Jacksonville/Northeast: UNIX Users of Jack¬ 
sonville meets the 2 nd Thursday of each month. 

Tom Blakely (904) 646-2820 

uflorida!unf7!tfb 

Emilie Olsen (904) 390-3621 


FL - Melbourne: the Space Coast UNIX Users 
Group meets at 8pm on the 3 rd Wednesday of each 
month at the Florida Institute of Technology. 


Bill Davis (407) 242-4449 

bill@ccd.harris.com 


FL - Orlando: the Central Florida UNIX Users 
Group meets the 3 rd Thursday of each month. 

Mike Geldner (407) 862-0949 

codas!sunfla!mike 

Ben Goldfarb (407) 275-2790 

goldfarb@hcx9.ucf.edu 

Mikel Manitius (407) 869-2462 

{codas,attmail) Imikel 


FL - Tampa Bay: the Tampa UNIX Users Group 
meets the 1 st Thursday of each month in Largo. 

Bill Hargen (813) 530-8655 

uunet!pdn!hargen 

George W. Leach (813) 530-2376 

uunet!pdn!reggie 


GA - Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Marc Merlin (404) 442-4772 

Mark Landry (404) 365-8108 


MI - Detroit/Ann Arbor: The SouthEastem Mich¬ 
igan Sun Local Users Group meets jointly with the 
Nameless UNIX Group on the 2 nd Thursday of each 
month in Ann Arbor. 

Steve Simmons home: (313) 426-8981 

scs@lokkur.dexter.mi.us office: (313) 769-4086 

K. Richard McGill Bill Bulley 

rich@sendai.ann-arbor.mi.us web@applga.uucp 


MI - Detroit/Ann Arbor: dinner meetings the 1 st 
Wednesday of each month. 

Linda Mason (313) 855-4220 

michigan!/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 

MN - Minneapolis/St. Paul: meets the 1 st Wednes¬ 
day of each month. 

UNIX Users of Minnesota Robert A. Monio 

17130 Jordan Court pnessutt@dmshq.mn.org 

Lakeville, MN 55044 (612) 220-2427 
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MO - St. Louis: 

St. Louis UNIX Users Group Eric Kiebler 

Plus Five Computer Services plus5!sluug 

765 Westwood, 10A (314) 725-9492 

Clayton, MO 63105 


NE - Omaha: meets monthly. 

/usr/group/nebraska Eric Johnson 

P.O. Box 31012 eric@null.uucp 

Omaha, NE 68132 (402) 422-5489 


New England - Northern: meets monthly at differ¬ 
ent sites. 

Peter Schmitt 

Peter.Schmitt@dartvax!dartmouth.edu 
Kiewit Computation Center (603) 646-2085 

Dartmouth College 
Hanover, NH 03755 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Peter J. Holsberg mccclpjh 

Mercer County (609) 586-4800 

Community College 
1200 Old Trenton Road 
Trenton, NJ 08690 


NY - New York City: Unigroup of New York City 
meets every other month in Manhattan. 

Unigroup of New York City 
G.P.O. Box 1931 
New York, NY 10116 

Peter Gutmann (212) 618-0973 

peterg@murphy.com 


OH - Columbus: The Columbus Local UNIX 
Group meets the 1 st Monday of each month. 

Mark Verber verber@mps.ohio-state.edu 

Physics Department (614) 292-8002 

Ohio State University 
Columbus, OH 43210 


OK - Tulsa: the Tulsa UNIX Users Group, $USR, 
meets the 2nd Wednesday of each month. 

Stan Mason (918) 560-5329 

tuIsixJsmason@drd.com 

Mark Lawrence (918) 743-3013 

mark@drd.com 


PA - Philadelphia: the UNIX SIG of the Philadel¬ 
phia Area Computer Society meets the morning of 
the 3rd Saturday of each month. 


G. Baun, UNIX SIG rutgers!{bpa,cbmvax}! 

do PACS temvax!pacsbb!{gbaun,whutchi) 

Box 312 

La Salle University 
Philadelphia, PA 19141 


TX - Austin: CACTUS meets the 3 rd Thursday of 
each month. 

Capital Area Central Texas UNIX Society 
P.O. Box 9786 
Austin, TX 78766-9786 

officers@peyote.cactus.org 

James Johnson (512) 331-3781 

jjhnsn@cs.utexas.edu 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 


TX - Houston: the Houston UNIX Users Group 
(Hounix) meets the 3 rd Tuesday of each month. 

Hounix answering machine (713) 684-6590 

Bob Marcum, president (713) 270-8124 

Chuck Bentley, vice-president (713) 789-8928 

chuckb@hounix.uucp 

TX - San Antonio: the San Antonio UNIX Users 
meets the 3 rd Thursday of each month. 

Jeff Mason gatech!petro!hpsatb!jeff 

Hewlett Packard (512) 494-9336 

14100 San Pedro 
San Antonio, TX 78232 


WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
P.O. Box 820 

Mercer Island, WA 98040-0820 
uw-beaver!tikal!camco!bill 


Washington, D.C.: meets the 1 st Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 350 
Vienna, VA 22182 

Alan Fedder (703) 448-1908 


CANADA - Toronto: 

Evan Leibovitch (416) 452-0504 

143 Baronwood Court evan@telly.on.ca 

Brampton, Ont. Canada L6V 3H8 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
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